Agent 走向生产：从任务完成到证据闭环

Agent 走向生产：从任务完成到证据闭环封面图

一个 Agent 能调用工具、输出 JSON，只能说明流程跑通。生产系统还要回答：结果有依据吗？工具失败有没有被掩盖？修改之后，正常任务会不会反而变差？

可信的 Agent，需要把业务判断、错误处理和效果验证连起来。 下文用风险事件抽取说明这条路径。企业名称、故障和视频片段均为教学模拟，不代表实际项目测量。

一、先定义什么算完成

假设原文说：“9 月 1 日，乙市某设备公司暂停生产，原因不明。”模型很容易填出时间、地点、企业和事件类型，但字段完整不等于事实正确。

结果应分清三类信息：

事实：原文明确提到暂停生产。
推断：结合上下文，乙市可能是厂区所在地。
未知：年份、停产原因、企业工商全称尚未确认。

“暂停生产”不能扩写成倒闭，“原因不明”不能补成经营困难。厂区所在地也不一定是注册地址；按乙市强行过滤工商记录，反而可能排除正确主体。

因此，事件抽取和主体确认应分别记录状态。即使企业尚未确认，原文线索仍然可以保留；查到一家同名公司，也不能直接把事件挂到它名下。允许有依据的部分结果，比强迫填满字段更可靠。

二、什么时候值得拆成多个 Agent

如果确认企业只需要一次查询，主 Agent 直接调用工具就够了。真正值得拆分的情况，是调查需要反复搜索、阅读网页和比较候选，大量中间材料开始干扰主任务。

例如，原文只提到“星旅项目组暂停到岗”。搜索找到一张招聘页，列出了某软件公司，但招聘发布者可能是外包商，不能立即认定它就是事件主体。这样的调查可以交给独立上下文中的 subagent。

flowchart TD
    A["主 Agent：保留原文与事件要素"] --> B["委派原文线索、来源和确认目标"]
    B --> C["工商 subagent：独立调查上下文"]
    C --> D["搜索、查询并核验候选关系"]
    D --> E{"证据充分或预算耗尽？"}
    E -->|否| C
    E -->|是| F["返回确认状态、证据和缺口"]
    F --> G["主 Agent 合并结果"]

拆分的收益是隔离调查材料，代价是额外调用和交接损失。委派不能只传公司名，还要传相关原文、地点角色和待确认的问题；返回时必须区分候选与结论。

如果调查很短，或高度依赖主任务的完整语境，保持单 Agent 反而更合适。拆分依据是任务独立性和上下文干扰，不是工具数量。

视频读取等能力也可以封装为 Agent as a Tool：外部通过稳定接口调用，内部由 Agent 选择工具并检查结果。先读标题与描述，有事实缺口再解析视频，避免每条内容都走昂贵流程。

三、工具失败，不能变成业务结论

工商查询超时，与查询成功但没有候选，是两回事。前者表示“还不知道”，后者才表示“这次查询未找到”。如果工具把二者都返回为空列表，后续模型很难正确处理。

错误控制至少需要三道约束：

工具协议区分成功、空结果和错误，保留错误类型。
运行时限制重试次数、总时长和调用预算，权限错误不能靠无限重试解决。
结果接受检查拦截明确违规，例如没有工商记录，却标为“主体已确认”。

预算耗尽后，可以返回“事件已抽取、主体未确认”，或转人工复核。不能为了交付完整结果，凭模型记忆补一家企业。

程序检查只能拦截确定性错误，不能证明语义真实。 引用存在，不代表引用支持结论；招聘页真实，也不代表招聘公司就是风险主体。这些关系仍需业务评估。

四、写入超时后，不要重新生成再提交

另一个容易忽略的失败发生在结果写入时：存储已经成功，但响应丢失了。执行器看到超时，如果重新运行 Agent 并新增记录，就可能得到重复或矛盾结果。

解决办法是固定一次逻辑提交的标识 K 和内容 R。提交前持久保存二者；恢复时重试同一份内容，而不是让模型重新生成。

flowchart TD
    A["持久保存提交标识 K 与结果 R"] --> B["存储事务：按 K 检查或占位"]
    B -->|首次提交| C["同一事务写入业务结果与幂等记录"]
    B -->|同 K、同 R| D["返回首次提交凭据"]
    B -->|同 K、不同 R| E["报冲突，不覆盖"]
    C --> D
    D -->|响应丢失| F["重试原来的 K 与 R"]
    F --> B

这里不能只靠应用层“先查再写”，否则并发请求仍可能重复写入。需要数据库唯一约束裁决竞争，并将业务结果与幂等记录放在同一事务里，失败时一起回滚。

内容比较还要有稳定规则，避免 JSON 字段顺序造成伪差异。同 K、不同 R 必须报冲突。 这能防止一次提交的重复写入，但不自动解决不同任务抽到同一现实事件的业务去重。