Skip to content

Agent设计

定位:Agent = Model + Harness。模型只是「会回答」,真正让它「能交付」的是外面那层 Harness——把一台单次预测机器,装进一个不停转的循环里,持续地干活。本层关注:这层壳怎么搭、子 agent 怎么编排,以及 Harness 工程要解决的 4 件根本的事。

📚 出处:实践分享 · 第一章 Harness 是什么。完整科普:https://harness.brightw.cc/


Agent = Model + Harness
  • Model:预测下一个 token 的「大脑」,单次预测机器——会回答,但不会持续干活。
  • Harness:把原始智能转成「有用功」的装置——所有 agent 框架、工具调用、记忆、调度,拆开看都是它的一部分。
  • 一句话:「你要么是模型,要么是 Harness,没有中间地带。」

三阶段演进:Prompt → Context → Harness

Section titled “三阶段演进:Prompt → Context → Harness”

工程认知一层比一层往「系统」走——前一阶段是后一阶段的子集:

阶段管什么边界
STAGE 01 · Prompt 工程「这一次怎么问」一次请求,不是契约——换个说法结果就飘
STAGE 02 · Context 工程模型「能看到什么」(RAG / 记忆 / 压缩)必要,但只管输入
STAGE 03 · Harness 工程(当前)「模型怎么持续地干活」——整个运行时管循环、工具、记忆、注意力、领域注入

Takeaway:Prompt 管一句话,Context 管输入,Harness 管整个运行时。本 cookbook 站在第三阶段看问题。

Harness 的本质,是给「单次预测机器」装上一个不停转的循环——感知—行动—再感知:

① 生成 ──→ ② 评估 ──→ ③ 再来
↑___________ 模型重新感知 ___________↓

调用工具 = 行动,工具返回 = 感知;每次行动的结果,都成为下一次的输入。循环本身很「笨」,但正是这个笨循环,把会说话的模型变成能交付的 Agent。

Harness 工程的 4 件根本的事(👉 4 篇深入)

Section titled “Harness 工程的 4 件根本的事(👉 4 篇深入)”

笨循环之上,要解决 4 件根本的事——每一件一篇深入文章:

#这件事一句话深入
感知-行动循环工具调用=行动 · 工具返回=感知,让每次结果成为下次输入设计指南/Agent设计/感知-行动循环
记忆管理模型天生失忆;用记忆 / 检查点 / 压缩,让任务有历史设计指南/Agent设计/记忆管理
上下文管理上下文 ≠ 无限注意力;Harness 当守门人,只放最有用的进来设计指南/Agent设计/上下文管理
Skill 封装不重训模型,一份 Skill+本体+CLI 把通用模型变领域专家设计指南/Agent设计/Skill封装本 cookbook 主线

决定效果的从来不是单一模型,而是叠加:模型能力 + 上下文 + 工具设计 + 权限 + 验证 + 流程 + 指标

  • 产出带随机性:同样输入,输出会浮动——这是天性不是 bug。
  • 部件好 ≠ 整机好:像造车,每个零件按图做好,整车也不一定平稳上路 → 必须有系统工程方法。

造车类比(详见讲义 P8):

🚗 汽车🤖 Harness Agent
发动机(动力)模型(智能/推理力)
变速箱(把动力转成可控节奏)笨循环与调度
底盘车架(承载一切的结构基座)文件系统与上下文工程
电控/传感(感知环境、可被纠正)工具调用与评测反馈
  • ✅ 任务可拆成多个独立子任务(批量、并行调研、多视角评审)
  • ✅ 需要独立上下文避免污染主线(深挖、对抗式验证)——呼应 设计指南/Agent设计/上下文管理
  • ❌ 单步可直接完成 → 不要套 Agent

编排形态:fan-out(并行)/ pipeline(流水线)/ 判官面板 / 循环到收敛。

  • 🚫 一个万能 Agent 什么都干 → 职责不清、难复用
  • 🚫 子 agent 间需频繁通信 → 说明不该拆,或该用 pipeline
  • 🚫 为「显得高级」而并行 → 并行有 wall-clock 与 token 成本