AI Agent 开发讨论记录

一、Harness Engineering 的边界

核心问题

多多益善地给模型加约束，还是根据模型能力只设置必要边界？

两种失败模式决定边界

结构性失败（来自架构本身，scaling 无法消除）

• Attention sink、lost-in-middle、entropy collapse
• 这类约束是合理的 —— ERGO 针对的就是这类
• ERGO 的 entropy spike 是真实的 uncertainty 信号，有明确物理意义

能力性不足（训练/数据不足，随模型迭代改善）

• 不会用工具、不会拆步骤、不会自我纠错
• 很多 Agent 框架填补的是这类 gap
• 模型进化后，这些 harness 就成了技术债

边界判断标准

该加约束：

• 针对不会随 scaling 消失的结构性失败
• 有可观测、量化的信号驱动（不是"感觉应该"）
• 约束是 adaptive 的（ERGO 的阈值自适应是正确姿势）
• 不干涉模型本身的泛化能力

不该加约束：

• 在修补症状而非根因
• 约束是静态的，不随 context 动态调整
• 多个约束互相干涉，制造新的脆弱点

结论

不应该多多益善。约束叠加边际效益递减，但复杂度成本是乘法的。

实操原则：

1. 先测基线 —— 去掉 harness 之后 delta 是否值得其复杂度？
2. 信号驱动 —— 约束触发必须有量化信号，不要凭直觉硬编码
3. 保留卸载路径 —— 每个约束加入时就想好"如何移除"
4. 最少惊喜原则 —— 约束不能比模型原生行为更不可预测

ERGO 是相对好的例子：只在 entropy 超阈值时干预，平时完全退出 —— 必要且自适应。

二、多 Agent 系统中 MVP 项目的开发方式

四个阶段

Phase 0：范围收敛（最关键）

• 对每个 feature 问：“如果没有这个，用户无法完成核心任务吗？” → 砍到只剩 YES
• 输出：MVP_SPEC.md，含范围、非范围、每个模块的 Done 标准

Phase 1：任务分解

• 大模块 → 子任务（2-4小时粒度）→ 依赖关系图
• 每个任务必须是独立可验证的
• 输出：PLAN.md，每个任务含目标、输入输出、接受标准、依赖

Phase 2：Subagent-Driven 执行循环

1
2
3
4
5
6
7

[主控 Controller]
  └─ 读 PLAN.md，提取所有任务到 TodoWrite
  └─ 串行执行每个任务：
       ① 实现 Agent（TDD + 自我 review + commit）
       ② Spec 检查 Agent（spec 合规，不多不少）
       ③ 质量检查 Agent（仅在 Spec ✅ 后）
       ④ 任务标记完成 → 下一任务

Phase 3：收尾与验收

• 最终 Code Review Agent 做全局 review
• 跑完整测试

大规模项目特殊挑战

关键规则

• 绝对不并行实现任务 —— 并发写同模块必然冲突
• 实现 Agent 不读历史会话 —— Controller 精确注入，不继承脏历史
• Spec 检查放在质量检查前 —— 顺序不能乱

三、Critical Agent：评价能力的设计

模型选择

Judge Agent 和实现 Agent 需要不同能力：

LLM-as-Judge 的系统性偏差：

• Sycophancy bias：较弱模型倾向于认为输出"看起来不错"而通过
• Verbosity bias：更长的输出被认为更好
• Self-enhancement bias：同模型评价自己产出时倾向于赞同

结论：便宜 Judge = 质量门失效。实现 Agent 可以省，评价 Agent 不能省。

Prompt 设计原则

核心：把判断转化为核查清单，不要开放式评价

Critical Agent Prompt 结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

你是一个 Spec 合规检查员。职责是核验实现是否满足规格，不多不少。

【原始规格】{spec}
【实现产物】{code / output}
【执行证据】{test_results / logs}

按以下维度逐条评估，先推理再结论：
1. 功能完整性：规格要求的每个功能是否都实现了？
2. 范围合规性：是否有规格未要求但新增的内容？
3. 接口契约：输入输出是否符合定义？
4. 边界条件：edge case 是否有处理？

整体结论：
- PASS：所有条件明确满足
- FAIL：列出具体哪条未满足及原因

要求：保守判断。"看起来可能没问题"不等于 PASS，需要有证据。

关键设计点：

• 提供 Spec + 实现 + 证据三件套，缺一不可
• 强制先推理后结论（CoT before verdict）
• 显式校准语：“保守判断”、“需要证据” —— 对抗 sycophancy
• 维度分离：Spec 合规 vs 质量是两个独立评价

单任务成功 / 失败评价

四层评价体系（层级越高越可靠）：

失败分类体系：

1
2
3
4
5

SPEC_MISMATCH    — 做了错的事（不符合规格）
INCOMPLETE       — 部分正确，有遗漏
QUALITY_FAILURE  — 功能正确，实现有严重质量问题
PROCESS_FAILURE  — 违反约束（破坏 API 契约、引入副作用）
EXECUTION_FAILURE — 任务无法完成（被阻塞、环境问题）

不同失败的响应策略：

• SPEC_MISMATCH → 重新澄清 spec，重派实现 Agent
• INCOMPLETE → 把缺失部分拆成新任务
• QUALITY_FAILURE → 派 fix Agent 针对性修复
• EXECUTION_FAILURE → 升级模型 or 人工介入，不盲目重试

关键原则

成功标准必须在任务开始前定义，不是完成后决定"算不算成功"。

每个任务 spec 必须包含：

1
2
3

功能标准：给定输入 X，输出必须为 Y
非功能标准：响应时间 < T，无 hardcoded secrets
排除项：不应修改文件 Z