实体与关系：不只搜到名字，还要找对对象、核对联系
Auto 除了搜资料，还尝试把“这页里出现了什么名字”推进到“这个对象究竟是不是我们要找的，它和其他对象是什么关系”。**实体回答“是谁、是什么”，关系回答“谁在什么条件下，与谁发生了什么联系”。**这里说的是解题中的人、机构、作品、地点等对象，不是账号身份，也不是社区用户之间的社交关系。
这层很重要：**名字出现不等于身份确认，两个名字一起出现不等于关系成立，几条边连起来也不等于推理已经正确。**
#### 1．实体：把“看起来像”与“证据支持”分开
多个同名人物、同一机构的简称与全称、同一作品的不同版本，都可能使检索跑向错误对象。旧 Auto 用候选池与条件对账来减少“先看到谁，就认定是谁”的问题；它不是已经完成的通用别名消歧服务，基础归一仍主要是大小写、空白和名称匹配。
| 旧候选状态 | 表示什么 | 不能误读成什么 |
| --- | --- | --- |
| `candidate` · 候选 | 出现了可能相关的对象，条件还没核完 | 不是“已找到答案” |
| `probable` · 较可能 | 部分条件获得支持，仍有缺口 | 不是模型说得自信就能确定 |
| `confirmed` · 已确认标签 | 达到当时覆盖率与来源数量策略 | **不等于全部约束已满足**；旧默认阈值是覆盖率80%及至少2个来源，标签不是事实保证 |
| `rejected` · 已排除 | 某项条件被判断为有反证，记录排除原因 | 不应与“暂时没搜到证据”混为一谈 |
每个候选再拆成“条件 × 证据”的表，逐项区分：**有支持、存在矛盾、未证实**。条件可以是时间、地点、身份、参与作品等。**未找到证据，不等于已经证伪。**旧实现仍有词面覆盖、数值启发式、来源计数与阈值等限制，不能把这张表包装成不会误判的裁判。
#### 2．关系：从一堆网页，变成可追问的证据链
旧 `evidence_graph` 将工具结果整理为“主体—关系—客体”，提供来源、分数和落账步骤字段。例如：
说明性示例：为解释机制构造，不是实际评测成功截图
人物甲先核是不是同一个人
2021年在此任职 →需有对应原文／工具依据
机构乙全称、简称不能随意混用
位于 →另一条关系，单独取证
城市丙不能只因同城就认同一机构
即使这两条关系都有依据，也不能直接推出“人物甲参与了机构乙的论文丁”。如果原文只写“曾合作”，更不能自动改成“任职”。关系类型、方向和时间都需要分别核对。
这类关系也不一定都从文字抽取：有坐标和可靠数据时，“附近、距离、方位”可以通过工具计算，再把数据来源和计算结果带回现场；不能因为网页没写一句完整关系，就说问题无法继续。**旧源码有把部分脚本计算结果送入证据图的路径，但不保证所有数值或空间关系都能正确抽出来。**
图的作用，是帮助下一步看清还缺哪条联系、该去哪里补证据；不是让“图上有路径”代替推理。这是一份单任务中的轻量记录，**不是知识图谱数据库**，也不代表已经具备完整的时态、别名、跨文档实体链接和独立来源验证。源码有模型抽取与规则回退，但当前搜索增量入图调用没有传模型回调，不能把它宣传成每条关系都经过了语义抽取。
#### 3．多约束倒置识别：先有候选，再逐条件验证
有些问题不告诉你名字，而是描述“它在某地、某年发生某事、和两个对象有关”。把整段条件拆成宽泛关键词去搜，容易搜到很多相关词，却始终找不到正确对象。
Auto 为此尝试了**候选优先＋逐约束验证**：先提出少量待调查的名称，再围绕“候选全名＋未核实条件”取证，记录每个格子的状态。如果结果不断偏离候选，尝试换候选或换方向，而不是机械增加搜索次数。**模型先验生成的是假设，不是证据。**
这里也不能把矩阵全绿当成闭环完成：旧矩阵函数不会独立核实证据ID，所查的调用点还可能传空证据ID。因此每条条件能否追到具体原文或计算结果，仍是必须保留的缺口。
一个候选证据还少，未必应该立刻丢掉；需要保留已有依据，找能区分候选的条件。旧“软锁”用于减少末端随意换答案，但锁错也会放大错误，所以它又加入了候选间比较与排除记录。**这是走过的探索，不是今天要把软锁、黑名单或强制换答案整包复制给所有 Harness。**
#### 4．源码确实有这层，但真实效果与旧控制必须分开
旧实际运行中可以看到两条有代表性的反例，它们不是本次构造的示例：
| 旧运行观察 | 对应机制为什么重要 | 这份记录不能证明什么 |
| --- | --- | --- |
| **ER1：资料到了，却认错对象。**一道人物识别题收到了14条带ID的证据，却将搜索服务名称写成候选并标为“有支持”。同条理由还写着“4／8条件覆盖、仍缺关键证据”，未解决条件数组却为空。 | 候选类型、条件核验和明确缺口必须对应起来；引用了多少条资料，不等于找对了实体。 | 这不是两个同名人物混淆的实证，也没有证明该候选已经提交为最终答案，更不能说之后已修好或因此提分。 |
| **ER2：关系没核清，状态先说完成。**一条“人物—书籍—书评—场所及日期”的任务中，槽位残片和人名先后被标成全部条件覆盖并锁定；后续才明确缺哪两条关系。 | 关系类型与答案类型都要核实，不能让局部词面命中或状态标签掩盖缺失的联系。 | 后续片段只有目标、拟议动作和选工具记录，没有对应执行回执；不能写成关系已经补齐、方向已纠正或最终答对。 |
两例中的 `supported`／`selected` 是旧运行事件里的候选状态，不能与前面四态模块的 `confirmed` 直接当成同一个字段。它们共同提醒我们：状态如何计算、由谁消费、缺口有没有保留下来，都需要看实际记录。
两份事件文件的 `run_id` 都是 `unknown`，且跨多个时间片段；本轮未恢复完整的修前修后配对，所以只用来说明真实失败形态，不用来计算成功率或归因提分。相关历史复盘可查[实体与关系Trace诊断](https://km.sankuai.com/collabpage/2782515730)、[8月下旬周报](https://km.sankuai.com/collabpage/2782703397)；这些原文中的作者归因也不能代替完整实验。
另外，两份已读的 Auto 旧检查点中，一份确实保存了4个节点、2条图边，另一份图为空。这证明前者存过结构化关系，不证明关系正确、被采用或改善了答案；图为空也不足以断言历史上从未运行过。
当前源码仍有几个特别需要说清的边界：
- **图保存方向，遍历却可以反着走。**`find_paths` 做的是无向邻接探索，所以“能从甲走到乙”不证明关系可以反过来解释。落账步骤也不等于关系真实生效时间，不能当成时态推理已经完成。
- **重复不等于独立验证。**同一条边再次出现就会加分，即使来自同一来源；这个分数**不等于正确概率**。来源字段允许为空，字符串不天然等于独立信源，裁剪图时还可能丢掉部分来源列表。
- **已确认标签不等于全部条件真成立。**覆盖率、关键词匹配、数值矛盾判断都有误判空间；图存在或 `confirmed` 不应让剩余缺口消失。
- **旧控制仍会干预结果。**旧严格门可能因为未知条件较多就阻止提交，旧黑名单可能让误排除难以恢复，部分收尾路径还会用软锁替换最终答案。这些行为有源码，不应美化为“只是提供上下文、完全不控制”。
这次使用**明确构造的内存输入**核对了其中三件事：4／5条件覆盖、2个来源会得到 `confirmed`；同一来源重复出现会让边分数从0.7升到约0.8；从关系客体也能沿邻接返回主体。它们验证的是当前函数的行为，**不是新增业务案例或实体推理效果评测**。原产品代码没有因此修改。
对今天军团最值得继承的是：**候选是谁、哪些条件已有依据、哪条关系仍缺证据、反证是什么，以及这些事实怎样交给下一位成员继续使用。**不是再建一个统一总裁判。当前 Auto 的答题角色已退出本地默认池；这套实体／关系方法是否都已拆成各家可用的工具、是否稳定提高新任务质量，仍需要独立的调用与结果证据，不能从源码存在直接推定。