7.5 · Agent 与闭环
采纳与证明是价值的闸门；生成不是。
LangChain Agent 跑通 demo 只证明「能生成」；WCN 闭环要求证明「推动了结果」。因此必须记录：哪条输出挂在哪个 task、谁采纳、采纳后触发了什么状态变更、最终证据是否过 Proof。没有这条链，只是又一个聊天窗口。
进入闭环的主路径
任务派发（含类型与验收标准）→ Agent 在授权内执行 → 结构化输出落库 → 节点 owner 采纳/驳回/修订 → 状态机推进 deal 或 task → 结果证据提交 → Proof Desk 审核 → 生成 PoB 记录 → 进入结算与信誉层
Agent 的价值是可识别的结果推动力：系统能区分「生成了 10 页」与「其中 3 段被采纳并导致会议召开/条款修改/打款条件满足」。
Agent 输出进入 Proof 的必要条件
任务 ID 绑定每条机器输出关联
task_id（或等价句柄）；禁止游离在私聊或离线文档里的「幽灵结果」。输入与版本留痕模型名、版本、温度或等价参数、检索片段 ID、关键附件哈希；便于复现与争议时取证。
人类采纳记录显式事件：
adopted_by、timestamp、可选修改 diff；与 Copilot 隐式「用户复制走了」不同，必须结构化。结果关联可追溯到 deal、里程碑或链上/链下业务事件（如合同归档、上所公告）；否则无法做归因结算。
缺任一条件 → 归类为「工具生成物」，不得计入 PoB；与 TradFi 中「没有交易编号与工作底稿的邮件」无法入账同理。
三个具象工作流示例
融资材料迭代
Task：「A 轮材料 v3 风险章节」。Research Agent 拉取竞品风险披露 → 输出带引用草稿 → 节点删减采纳 → 修订后 PDF 哈希上传 → Proof 关联「定稿用于投资人会议」→ 会议闭环后再记 PoB。
资本匹配
Deal Agent 输出排序前 5 项目与匹配理由 → 节点仅采纳其中 2 个并创建 intro Task → 后续邮件由人发送；PoB 只记录被采纳推荐与后续已验证结果，不记录未采纳排序。
投后监控
Liquidity Agent 日报异常段落 → Execution Agent 生成内部 Slack/任务文案草稿 → 风控负责人采纳一条并创建「跟进托管行」Task → 回执进入证据包 → Proof 通过后进 PoB。
反例：看似很忙，零闭环
- AutoGPT 式无界探索产出大量笔记，无 task、无 owner → 噪音。
- Copilot 生成漂亮邮件但未从 WCN 任务发送、无采纳标记 → 不可归因。
- Agent 建议上所时间线，节点口头转发给项目方但系统无状态 → 无法验证。
这一步决定什么
AI 是否只是工具进入闭环才成为正式执行层；否则与任意 LLM 包装无异。
Agent 是否可被结算无 Proof 链则无 PoB；激励与分润缺少凭据。
Agent 是否可治理采纳率、错误采纳回滚、模型 A/B 效果都可度量，才能升级或暂停具体 Agent 配置。
WCN 差异化不是「接入了 GPT/Claude/Gemini」，而是多节点业务网络里第一次把机器输出接到统一证据与结算语义上。
验收标准建议：能否在争议中用日志在 30 分钟内讲清楚——谁让 Agent 做了什么、采纳了什么、最终业务结果是什么。能做到，则闭环设计基本合格。