Skip to main content

Agent 构建方法

核心公式：Agent = Model + Harness

Harness = Agent 减去 Model —— 在一个 Agent 系统里，除了模型本身以外，几乎所有决定它能不能稳定交付的东西，都算 Harness。

harness

一、三代工程演进（包含关系，非替代关系）​

阶段核心问题优化对象擅长局限
Prompt Engineering模型有没有听懂你在说什么？指令的表达定义任务、约束输出、激发模型已有能力无法弥补缺失知识、无法管理动态信息、无法处理长链路状态
Context Engineering模型有没有拿到足够且正确的信息？输入环境（信息的供给）在合适时机把正确信息送进模型信息给对了，模型也不一定能稳定执行正确
Harness Engineering模型在真实执行中能不能持续做对？整个运行系统持续观测、持续纠偏、最终验收结果—

边界递增关系：Prompt ⊂ Context ⊂ Harness

  • Prompt 是 Context 的一部分；
  • Context 是 Harness 的一部分；
  • Harness 是对整个运行系统的工程化。

拜访客户类比​

层次对应动作重点
Prompt把任务讲清楚：先自我介绍 → 介绍方案 → 分析需求 → 确定下一步把话说明白
Context准备资料：客户背景、沟通记录、报价、竞品情况、会议目标把信息给对
Harness让技术专家陪同、关键节点实时汇报、发现偏差马上纠正、按标准验收结果持续观测 + 纠偏 + 验收

二、成熟 Harness 的六层架构​

第一层：上下文管理（Context Layer）​

原则：模型能够在正确的信息边界内思考。

检查项说明
角色 / 目标 / 成功标准模型知道自己是谁、任务是什么、什么算做好
信息裁剪与选择上下文不是越多越好，而是越相关越好
结构化组织固定规则、动态任务、运行状态、外部检索结果 —— 分层清楚，避免自我污染
渐进式披露（SGAO 思路）不一次性暴露全部能力描述，只给最少量元信息；需要时再动态加载详细 SOP / 参数 / 脚本
Context Refresh 机制上下文过长时，不仅压缩，更要换一个干净的新上下文将工作交接过去（类似进程重启而非清缓存）

第二层：工具系统（Tool Layer）​

原则：模型从"文本预测器"变成"能做事的执行者"。

检查项说明
工具集合理性工具太少 → 能力不够；工具太多 → 模型乱用。需精心选择
调用时机控制不该查时别乱查，该查时别硬答
结果回流处理工具返回的大量结果不应原封不动塞回模型，需提炼、筛选、保持与任务的相关性

第三层：执行编排（Orchestration Layer）​

原则：模型下一步该做什么，必须有轨道。

检查项说明
任务分解将模糊需求拆解为模型能执行的小任务
标准执行流程理解目标 → 判断信息是否充足 → 不足则补充检索 → 分析 → 生成输出 → 检查输出 → 不满足则修正/重试
防止"想到哪做到哪"避免模型自由发散，确保交付完整而非半成品

第四层：记忆与状态（Memory & State Layer）​

原则：没有状态的 Agent 像失忆者，不知道自己做了什么。

检查项说明
当前任务状态当前进行到哪一步、中间结果是什么
进化中的中间结论哪些结论已确认、哪些问题还未解决
长期记忆与用户偏好跨会话持久化的信息
三类分离以上三类必须分开管理，混在一起系统会越来越乱

第五层：评估与观测（Evaluation & Observability Layer）​

原则：系统不仅要会做，还要知道自己有没有做对。

检查项说明
输出验收标准明确的、可检查的交付标准
环境验证不只看代码/文本，要在真实环境中操作、截图、检查实际结果
自动化测试可重复运行的测试用例
日志与指标追踪可查 Log、查监控
生产与验收分离干活的人和验收的人必须分开（避免自评偏乐观）—— Planner / Implementer / Evaluator 角色分离

第六层：约束、校验与失败恢复（Guardrails & Recovery Layer）​

原则：在真实环境里，失败不是例外而是常态。

检查项说明
约束（Constraints）明确哪些能做、哪些不能做
校验（Validation）输出之前和输出之后都要检查
恢复（Recovery）失败后能重试、切换路径、或回滚到稳定状态
隔离环境每个任务在独立沙箱中运行，互不影响

三、一线公司实践要点​

Anthropic 实践​

实践要点
Context Refresh（上下文刷新）上下文过长时不只是压缩，而是启动一个全新干净的 Agent 并交接工作状态（类似进程重启）
生产 / 验收分离Planner 负责需求 → 规格；Implementer 负责逐步实现；Evaluator 像 QA 一样真实操作页面、检查交互结果
Evaluator 真实验证不是抽象审查代码，而是在具体环境中操作、截屏、检查实际行为

OpenAI 实践​

实践要点
人类角色转变工程师不写逐行代码，而是设计环境：拆解任务 → 补充缺失能力 → 建立反馈回路
Agent 自测闭环Agent 接浏览器截图 + 日志系统 + 指标系统，能自己跑、看结果、发现 Bug、修复、再验证
经验规则化资深工程师经验写成系统规则（模块分层、依赖约束、拦截条件、修复方法），规则不只报错，还把"怎么修"一起反馈给 Agent
隔离执行每个任务在独立沙箱环境运行

Cursor 实践​

实践要点
渐进式披露早期把所有规范塞进一个巨大的 .md 导致 Agent 更混乱；改为目录式引导，核心文件只保留索引，详细内容拆分到子文档，按需加载
上下文窗口是稀缺资源塞得太满 ≈ 什么都没说；信息不是一次性全给，而是按需暴露

四、评估清单（对标检查用）​

对任意 Agent 系统，逐项检查是否满足以下标准：

A. Prompt 层面​

  • 是否清晰定义了角色、任务目标、成功标准？
  • 是否有明确的输出格式约束？
  • 是否使用了示例引导？

B. Context 层面​

  • 是否在正确时机提供正确信息？
  • 是否对上下文做了裁剪和结构化组织？
  • 是否采用渐进式披露（按需加载）而非一次性全量灌入？
  • 是否有上下文刷新 / 交接机制应对长任务？
  • RAG / 检索结果是否经过筛选和排序？

C. 工具系统​

  • 工具集是否精心筛选（不多不少）？
  • 是否有调用时机的控制逻辑？
  • 工具返回结果是否经过提炼再回流模型？

D. 执行编排​

  • 任务是否被合理拆解为可执行的步骤？
  • 是否有标准执行流程（理解 → 检索 → 分析 → 生成 → 检查 → 修正）？
  • 是否防止模型自由发散导致交付半成品？

E. 记忆与状态​

  • 是否管理当前任务状态（进度、中间结果）？
  • 是否区分短期状态和长期记忆？
  • 不同类型的状态是否分离管理？

F. 评估与观测​

  • 是否有独立于执行者的验收机制？
  • 是否在真实环境中验证（而非仅代码审查）？
  • 是否有自动化测试和日志追踪？
  • 生产与验收是否分离？

G. 约束、校验与恢复​

  • 是否明确了行为边界（能做 / 不能做）？
  • 输出前后是否有校验步骤？
  • 失败后是否能重试 / 切换路径 / 回滚？
  • 是否在隔离环境中执行？

五、核心认知​

  1. 同样的模型，不同的 Harness，表现差距巨大——真正决定上限的可能是模型，但决定能不能落地、能不能稳定交付的是 Harness。
  2. Agent 出了问题时，修复方向几乎从来不是"让它更努力"，而是"确定它缺了什么结构性能力"。
  3. AI 落地的核心挑战正在从"让模型看起来更聪明"转向"让模型在真实世界里稳定工作"。
  4. 上下文窗口是稀缺资源——信息优化不只是给得更多，而是按需给、分层给、在正确的时机给。
  5. 生产和验收必须分离——只要评估者足够独立，系统就能形成有效的"生成 → 检查 → 修复 → 再检查"循环。