为什么你的 AI Agent 需要认知架构 — 当 Sonnet 打败 Opus

为什么你的 AI Agent 需要认知架构 — 当 Sonnet 打败 Opus

我们花了两天时间让一个 Opus 级别的 Agent 产出了 19 份市场分析报告。用户一份都没看完。与此同时，团队里另一个跑在 Sonnet 上的 Agent，用更低的成本实现了远超预期的表现。差距不在模型，在认知架构。

---

一、问题：19 份报告，零反馈

Scout 是我们在 OpenClaw 框架上构建的 AI 求职市场分析 Agent，基于 Opus 4.6，负责分析某招聘平台的岗位数据（约 1000 条），输出市场洞察报告。

上线两天，Scout 表现得非常"勤奋"——自动产出了 19 份分析报告，覆盖薪资分布、技能需求、城市对比等多个维度。表面上看，产出效率惊人。

但用户的反馈是：零。

不是报告写得烂——格式工整、数据丰富、图文并茂。问题在于：用户不是数据分析专家，面对一份直接给出结论的报告，他无法判断分析是否正确。报告说"某技能溢价 28%"，用户既不知道这个数字怎么来的，也不知道用了什么分析方法，更不知道该不该信。

看完找不出大问题，但也给不出有价值的反馈。Scout 进入了一个死循环：产出 → 无反馈 → 继续产出 → 继续无反馈。

我们复盘时发现了四个结构性问题：

1. 无验证机制：报告中的每个数字结论，全靠 LLM"自觉"正确。没有任何独立验证环节。
2. 无学习循环：Scout 遇到不熟悉的分析方法时，直接猜。不会主动研究，不会承认不会。
3. 无方法论支撑：分析缺乏理论框架，结论强度与样本量不匹配。
4. 反馈环断裂：报告太大（5000 字、多个论点），用户无法在任何粒度上给出有效反馈。

这些问题不是 Opus 模型不够强——恰恰相反，更强的模型让 Scout 更擅长"看起来很专业"，掩盖了分析链路的缺失。

---

二、对标：同一个团队，两种表现

转折来自团队里的另一个 Agent——Cinema。

Cinema 是一个视频模板制作 Agent，跑在 Sonnet 4.6 上（成本约为 Opus 的 1/5）。它的任务是根据设计需求生成 Motion Graphics 模板。令人意外的是，Cinema 的表现远超 Scout——不仅产出质量高，而且会主动学习、自我改进。

我们观察到 Cinema 的一个典型行为链：

1. 用户反馈"太 AI 味了" → Cinema 制定学习计划
2. 自主执行 6 轮 web_search（色彩理论、排版原则、竞品分析）
3. 主动向用户报告学习过程（"我需要和你同步我学到了什么"）
4. 双方讨论达成共识 → 写入规则文件
5. 立即应用新规则 → 失败 → 自我诊断方法论错误 → 更深入学习
6. 次日自发审计全部 13 个旧模板并逐个重构

一个 Sonnet 级别的 Agent，在没有特殊调优的情况下，展现出了持续学习和自我改进的能力。而跑在 Opus 上的 Scout，只会重复产出无人问津的报告。

我们把两个 Agent 放在一起对比，找到了根本差异：

维度	Cinema（Sonnet）	Scout（Opus）
认知单元	一个模板（小、闭环）	一份报告（大、开环）
反馈信号	内生的（编译→渲染→ffprobe）	无（报告写完就写完了）
学习循环	有（识别缺口→研究→讨论→沉淀）	无（不会就猜）
方法论	有（15 条经验规则）	无（分析靠直觉）
用户角色	共同学习者 + 审核者	被动接收者
质量来源	工具链强制（不渲染就没 MP4）	提示词建议（"请自检"）

差距不在模型能力，在认知架构——Agent 的思考方式、工作流程、质量保障机制的结构性设计。

---

三、核心洞察：质量来自架构约束，不来自提示词建议

这个发现可以浓缩为一句话：

你无法通过在 System Prompt 里写"请仔细检查"来获得可靠的输出质量。质量必须来自架构层面的结构性约束。

Cinema 之所以表现好，是因为它的工具链提供了物理级别的约束：模板必须能编译、必须能渲染、渲染结果必须通过 ffprobe 检验。不通过就没有产出。这些约束不依赖 LLM 的"自觉"——即使模型想偷懒，工具链也不允许。

而 Scout 的质量保障全部停留在提示词层面："请在输出前自检数据准确性"。这等于告诉一个人"请确保你的论文没有错误"——说了等于没说。

但分析任务和视频制作有一个本质区别：视频渲染有二值反馈（成功/失败），分析洞察没有。

"某技能在市场中占比 11.1%"可以通过重跑 SQL 验证，但"现在学这个技能等于抢占先发优势"——这个判断没有自动化的验证方式。

我们因此把 Agent 的工作分成了三层，每层有不同的质量保障机制：

层	含义	验证方式	自主程度
数据层（What）	客观事实	工具自动验证（SQL 重跑）	自主
方法层（How）	分析框架	用户确认	半自主
洞察层（So What）	解读建议	用户判断	协作

承认局限比假装全能更有价值。 Scout 的自主闭环只覆盖数据层和方法层，洞察层是人机协作。这是 by design，不是缺陷。

---

四、理论基础（简述）

我们的设计参考了几个 Agent 架构领域的理论框架：

• CoALA（Cognitive Architecture for Language Agents）：分离工作记忆、长期记忆和决策循环
• Reflexion：失败→反思→写入记忆→下次不犯同样的错
• CoVe（Chain of Verification）：独立重新执行验证，防止确认偏误
• Critic-Actor 分离：生成和评估必须是独立操作

以上理论的详细内容不在本文展开。感兴趣的读者可以搜索相关论文自行了解。本文聚焦于这些理论在实际 Agent 系统中的工程化应用。

核心设计原则只有一条：质量来自架构约束，不来自提示词建议。

同时我们明确了一个重要认知：这套架构随模型能力正向缩放。Finding pipeline 的价值不仅是质量保障，更是分析过程的结构化输出。更强的 LLM 产出更好的方法论研究和更深的洞察，结构化过程让这些高质量产出更可理解、可学习、可复用。架构不会因为模型变强而贬值——恰恰相反，它会放大更强模型的优势。

---

五、认知单元：Finding 而非 Report

Cinema 的认知单元是"一个模板"——足够小、可独立验证、可快速迭代。Scout 需要同等粒度的认知单元。

"一份报告"作为认知单元太大了。5000 字、多个论点、多种分析方法混在一起——用户无法在任何单一维度上给出反馈，Agent 也无法在内部形成闭环验证。

我们引入了 Finding（发现）作为 Scout 的认知单元。一个 Finding 是最小的可验证分析单元，包含三层：

Finding = 一个观察 + 一个方法 + 一条证据链 + 一个解读

举例：

{
  "observation": "某技能在市场岗位中的渗透率",
  "method": "Rogers 技术扩散曲线",
  "evidence": [
    {"sql": "SELECT ...", "result": 57, "label": "包含该技能的岗位数"},
    {"sql": "SELECT ...", "result": 514, "label": "有效岗位总数"}
  ],
  "interpretation": "该技能渗透率 11.1%，处于 Early Adopter 阶段"
}

报告 = 多个 verified findings 的组装。 这等同于 Cinema 的 showreel = 多个模板的组装。

这个粒度选择带来了三个关键好处：

1. 可独立验证：每个 Finding 的数据层可以通过 SQL 重跑来验证，不需要理解整份报告的上下文。
2. 可增量反馈：用户可以逐个确认或否定 Finding 的方法论和解读，不需要一次性审核整份报告。
3. 可跨 session 复用：一个 Finding 一旦通过验证，可以被多份报告引用。

---

六、状态机：工具强制的质量门控

每个 Finding 有一个严格的状态机，由工具（finding.py）强制执行：

draft → learning → has_method → has_evidence → verified → complete

关键在于：状态转换不是 LLM 自己决定的，而是工具校验后才允许的。

• 没有绑定方法论的 Finding → 工具拒绝添加证据
• 没有通过验证的 Finding → 工具拒绝添加解读
• 报告组装工具 → 只接受 status=complete 的 Findings

这就是"架构约束"的含义：不是在提示词里写"请确保每个结论都有方法论支撑"，而是工具层面直接阻止没有方法论的结论进入下一步。LLM 想偷懒也偷不了。

验证机制：三个层次

Finding 的验证（verify）分三个层次，我们对每个层次的能力和局限都做了明确区分：

第一层：数据库稳定性 检查数据源是否在证据收集和验证之间发生了变化。如果数据被更新了，输出警告而非失败——让 Agent 决定是重新收集证据还是接受变化。

第二层：幂等性 重跑所有 SQL，对比结果是否与首次执行一致。这验证的是"同样的查询给同样的结果"，确保数据没有被 session 中的临时状态污染。

第三层：常识检查 预定义的合理性规则（如"薪资中位数应在合理范围内"、"百分比应在 0-100 之间"）加上方法论特定的验证规则（如"分位数定价法要求 P25 < P50 < P75"）。

我们诚实地承认 verify 的局限： 它不能验证"结论正确性"——即 Agent 写的 SQL 是否真的匹配了它想回答的问题。如果 Agent 想算中位数但写了 AVG（均值），SQL 会正常执行，verify 也会通过，但结论是错的。这一层的正确性只能由方法论库 + 用户审核来保证。

---

七、方法论库：让 Agent 学会学习

Scout 的旧架构中，遇到不熟悉的分析方法时，LLM 会直接猜。新架构引入了方法论库（methods/），这是 Scout 的核心资产。

方法论库和经验规则（learned-rules）互补但不合并：

	方法论库	经验规则
内容	分析框架、理论依据	操作经验、踩坑记录
层级	"怎么想"	"怎么做"
来源	主动研究 + 用户确认	失败后复盘
类比	Cinema 的设计理论	Cinema 的操作规则

学习循环

当 Scout 遇到知识缺口（没有合适的方法论来支撑当前分析）时，会触发学习循环：

检测到方法论缺口
    ↓
Scout 自主研究（web_search 中英文并行）
    ↓
整理研究摘要，保存方法论为草稿
    ↓
将学习成果发送给用户：
  "我找到了三种方法：
   1. 方法A — 原理和适用场景
   2. 方法B — 原理和适用场景
   3. 方法C — 原理和适用场景
   我建议用方法 C，因为我们的数据支持这种分析。
   你觉得哪个合适？"
    ↓
用户确认 → 方法论升级为"已验证" → 绑定到 Finding → 继续推进

这个循环直接复制了 Cinema 的成功模式：识别缺口 → 研究 → 分享用户 → 讨论 → 沉淀为规则。

降级机制

但这里有一个风险：如果用户不回复，整个 pipeline 就停滞了。旧架构至少还能产出（虽然质量差），新架构要求用户参与更频繁。

我们设计了一个降级机制：方法论发送给用户后 24 小时未确认 → 自动标记为"auto_approved"。Pipeline 继续推进，但报告中会标注"该方法论未经用户审核"。用户可以事后审核升级为正式验证，或打回重新研究。

这样 pipeline 不会完全阻塞，同时保持了质量透明度。

---

八、跨 Session 持久化：被低估的难题

在实际 Agent 框架中，session 管理是一个被严重低估的问题。

我们的场景中，Scout 有两种 session：

• 定时任务：每次全新 session（无历史上下文）
• 用户对话：持久会话

问题来了：用户在对话中说"这个方法论可以"，如果 Agent 不立即把这个确认写入持久化文件，下次定时任务启动时完全看不到这个反馈。

我们的解法是：所有状态变更必须通过 finding.py 工具完成，每次调用 = 一次文件写入 = 跨 session 可见。 工具成为 session 间同步的桥梁。

用户在对话中确认方法论
    ↓
Agent 立即调用工具更新状态 → 写入磁盘
    ↓
下次定时任务启动 → 读取文件 → 看到最新状态

这要求 SOUL.md（Agent 的行为指南）中必须明确写入一条铁律：收到用户反馈后，必须立即调用工具更新状态。不更新 = 下次定时任务看不到反馈 = 状态不同步。

同时，由于定时任务和用户对话可能并行运行，工具层使用文件锁（fcntl.flock）防止并发写入冲突。

---

九、对话模式判断：不是所有交互都要走 Pipeline

一个实际问题：用户随口问"这个技能热门吗？"，Scout 需要走完整个 Finding pipeline 才能回答吗？

不需要。我们在 Agent 的行为指南中定义了对话模式判断规则：

• 用户即时提问（"XX 多吗？"）→ 简短回答。如涉及定量结论，附一句"需要做成正式 Finding 吗？"
• 用户主动要求分析（"分析一下薪资结构"）→ Finding pipeline
• 定时签到 → 必须走 Finding pipeline

核心原则：数字出口必须有 Finding 背书，观点可以自由交流。

这个区分很重要。如果所有对话都强制走 pipeline，用户体验会极差。如果完全不走 pipeline，Agent 会永远选择"直接回答"来绕过约束。

---

十、实施策略：MVP 先行

我们没有一次性实现完整系统。实施分为两个阶段：

MVP（约 200 行代码，7 个命令）

只实现最核心的状态机链路：

• new：创建 Finding
• method：绑定方法论（轻量版，不校验方法论文件）
• evidence：收集证据
• verify：验证（仅幂等性检查，暂无常识检查）
• status/show/list：查询

MVP 验证的核心假设只有一个：Agent 愿意且能够使用 finding.py。 如果 Agent 持续绕过工具直接写报告，说明行为指南的约束力不够，需要先解决这个问题再继续投入。

完整实现（MVP 通过后）

补全剩余功能：

• 方法论文件管理（保存、确认、版本化）
• 学习循环（learn/learn-update）
• 反馈处理（approve/reject/abandon）
• 报告组装工具
• 常识检查、文件锁等增强

这个分阶段策略的关键在于：用最小投入验证最大风险。 最大的风险不是代码能不能写对，而是 LLM 会不会按我们设计的流程工作。

---

十一、已知的设计取舍

任何架构都有取舍。我们选择把这些取舍明确记录，而非假装完美：

1. 工具约束是"软约束"，不是物理约束

Cinema 的约束是物理的——不渲染就没有 MP4。Scout 的约束是社会契约式的——SOUL.md 告诉 Agent"你必须用 finding.py"，但 Agent 理论上可以直接在对话中输出分析。工具约束比纯提示词更强，但不是绝对的。我们通过 MVP 阶段验证这个约束是否足够有效。

2. 线性状态机可能限制强 LLM 的能力

当前状态机是线性的：draft → method → evidence → verify → interpret。优秀的人类分析师不是这样工作的——他们迭代、回溯、同时探索多条假设。更强的 LLM 可能更适合非线性的探索式分析。

我们选择先用线性流程起步，原因是：线性流程更容易验证和调试。非线性探索可以作为后续优化。

3. LLM 可以"合规地摸鱼"

Finding 系统约束了流程但不约束内容质量。Agent 可以完全遵守状态机，同时产出低价值的 Finding（比如"数据库共有 1000 条记录"——技术上完整，实际毫无洞察）。

这就是 Goodhart's Law：当指标变成目标，它就不再是好指标。我们通过用户审核环节（approve/reject）和协作有效性指标来缓解这个问题，但没有完美解。

---

十二、可迁移的设计模式

从 Scout 的重设计中，我们提炼了五个可迁移到其他 Agent 系统的设计模式：

模式一：选择正确的认知单元粒度

认知单元 = Agent 内部可独立验证和迭代的最小工作单元。

如果你的 Agent 产出的东西"太大、无法闭环验证"，那就需要拆小。Cinema 的模板、Scout 的 Finding、代码 Agent 的单个函数——都是正确粒度的认知单元。判断标准：用户能在这个粒度上给出是/否反馈吗？Agent 能在这个粒度上自动验证吗？

模式二：工具强制 > 提示词建议

任何你想保证的质量属性，都应该在工具层面强制，而非在提示词层面建议。

"请确保数据准确" → 不可靠。 "工具自动重跑 SQL 并对比结果" → 可靠。

这不意味着提示词没用。提示词定义 Agent 的行为倾向，工具定义不可逾越的边界。两者互补。

模式三：建设学习循环，而非执行循环

大多数 Agent 只有执行循环（接任务→做→交付）。优秀的 Agent 还有学习循环（识别缺口→研究→验证→沉淀）。

学习循环的关键不是"让 Agent 做 web_search"——而是整个链路：发现不会 → 主动研究 → 向用户报告学习成果 → 讨论达成共识 → 写入持久化知识库 → 后续任务自动引用。

Cinema 的 15 条经验规则不是我们写的——是 Cinema 自己在反复失败和学习中积累的。这些规则跨 session 持久化，越用越好。

模式四：区分你能验证什么和不能验证什么

对每一层产出，明确它的验证机制和自主程度。不要假装所有事情都能自动保证质量。

数据层用工具验证，方法层用用户确认，洞察层用协作讨论。把三者混为一谈（全部自动化或全部人工审核）都是错误的。

模式五：从第一天就设计跨 Session 持久化

如果你的 Agent 有定时任务，跨 session 状态同步是 Day 1 就必须解决的架构问题。

很多 Agent 在单 session 内表现完美，一旦涉及跨 session（定时任务、多轮异步交互），状态就丢失了。用户说"同意"，下次定时任务完全不知道。

解法不复杂：所有状态变更通过工具写入文件。但如果不从第一天就这样设计，后续改造的成本远大于一开始就做对。

---

结语

我们从一个 Opus Agent 产出 19 份报告零反馈的困境出发，通过对标同团队 Sonnet Agent 的表现差异，得出了一个核心结论：

Agent 的表现上限不取决于模型能力，取决于认知架构。

更强的模型会写更好的 SQL、研究更深的方法论、产出更有洞察力的解读。但如果没有架构来保证这些产出的可验证性、可追溯性、可学习性，再强的模型也只是在更高效地产出无人问津的内容。

认知架构不是在限制 LLM——它是在放大 LLM。

---

关于 OpenClaw： 本文中的 Scout、Cinema 等 Agent 基于 OpenClaw 框架构建。OpenClaw 是一个支持多 Agent、多渠道的 AI Agent 框架。

关于本文： 本方案由人机协作完成设计。文中描述的认知架构已完成设计文档，工具链进入实施阶段。我们计划在实际运行数据积累后发布效果对比的后续文章。