Agent Harness 工程实践深度解读

作者观点 文章将 AI 工程范式分为三代。

第一代关注"怎么把话说清楚"，第二代关注"怎么给 AI 喂对信息"。

第三代 Harness Engineering 关注"怎么让 Agent 可控地工作"。

类比：模型是 CPU，Harness 是操作系统——CPU 再快，OS 拉胯也白搭。

文章依据：代际对比表及 CPU/OS 类比，出自文章第三节。

影响：团队应评估自己处于哪一代，补齐后一代的能力。

作者观点 铁律一：上下文是稀缺资源，会被污染和干扰。

不要把"模型支持 200K"等同于"可以塞 200K"。

铁律二：Agent 是昂贵的，Skill 是廉价的。

铁律三：上下文是易失存储，文件系统才是持久内存。

铁律四：文档只是"建议"，Linter/CI 才是"强制"。

文章依据：四条铁律及对比表，出自文章第四节。

影响：构建 Agent 系统的团队应审视是否违反了这四条。

FACT 模式 1：双阶段架构。

Initializer 写 plan.md，Executor 读取执行，不共享 Context。

FACT 模式 2：工具签名即文档。

工具名是动词短语，参数带描述，返回值结构稳定。

FACT 模式 3：Sub-Agent 隔离。

独立 Context Window，只看必要工具。

FACT 模式 4：上下游反压。

Linter/CI 拒绝无效工作，错误信息本身是上下文工程。

FACT 模式 5：智能体审智能体。

换 Context 做 Review，避免"自我合理化"偏见。

FACT 模式 6：文档园丁。

定期扫描过期文档，持续小额偿还技术债。

文章依据：六大模式索引表及描述，出自文章第六节。

影响：为 Agent 工程师提供可复用的"设计模式手册"。

FACT 第一版是全能招聘 Agent。

600+ 行 Prompt、13 个工具，跑了一周问题全冒出来。

上下文爆炸、工具选错、状态丢失，同时违反铁律一和铁律二。

FACT 第二版按"Agent 贵、Skill 廉"重新设计。

人岗匹配 Agent（RPA 专才，4 工具）+ 招聘沟通 Agent（聊天专才，5 工具）。

FACT 改造后端到端准确率稳定超过上线门槛。

日志分钟级定位，人岗匹配 Agent 已复用到内推系统。

文章依据：悟空架构图及改造对比表，出自文章第七节。

影响：企业级 Agent 开发者可直接参考该架构。

FACT 悟空招聘的聊天 Agent 是唯一"会主动给真人发消息"的 Agent。

三层护栏使事故率从"每周一两次"降到"记不清上一次"。

FACT 行业标杆对位：Anthropic 重双阶段，LangChain 重自我验证。

Ghostty 重 AGENTS.md，Cursor 重反馈回路。

作者观点 各家护栏落点不同。

四根护栏在五层里都有落点才是成熟团队。

文章依据：三层护栏表格及行业标杆地图，出自文章第 7.5 节和第八节。

影响："对外发言"和"操作用户数据"的 Agent 必须早期就上护栏。