过去两年，AI Agent 的讨论不断更换关键词。
先是 Prompt Engineering，后来是 Context Engineering，再后来是 Harness Engineering、Memory、Long-running Agent 和 Loop Engineering。
这些概念看起来越来越复杂，但它们其实都在回答同一个问题：
如何让一个会生成答案的模型，变成一个能够持续完成工作的系统？
Simon Willison 将 Agent 概括为：
An LLM agent runs tools in a loop to achieve a goal.
也就是：模型调用工具，在一个环路中持续行动，直到完成目标。
这个定义真正重要的地方，不是“模型”，也不是“工具”，而是后半句：
在环路中，朝一个目标持续前进。
ReelOS.AI 禅定｜一句话看懂本文
模型只能完成一次推理，真实工作需要连续行动。
- 连续行动必然遇到上下文耗尽、状态丢失、执行失败和错误自验。
- Agent 的核心不是让模型更聪明。
- 而是把目标、状态、执行、验证和恢复组织成一条稳定的工作环路。
- 所以，Agent 的产品单位应是“可验证的工作”，而不是“一次模型回复”。
一、Agent 的核心误区：把系统能力误认为模型能力
很多 Agent 产品的第一版，通常由三部分组成：
- 一个 System Prompt；
- 一组工具或 MCP；
- 一个支持连续调用模型的循环。
这足以做出一个令人惊艳的 Demo。
但 Demo 能运行，不代表系统能工作。
一旦任务超过十几分钟，Agent 很快会暴露出一系列问题：
- 忘记最初目标；
- 重复执行相同操作；
- 被大量工具结果淹没；
- 修改了代码，却没有验证真实功能；
- 做完一小部分，便宣布整个任务已经完成；
- 进程中断后，不知道该从哪里继续；
- 多轮摘要后，目标逐渐发生偏移。
这些问题往往被归咎于模型不够强。
但更准确的判断是：
模型决定单步能力，系统决定长程能力。
一个模型可以很擅长写代码、分析资料和调用工具，但它不会天然拥有项目管理、进度交接、异常恢复、质量门禁和成本控制能力。
这些能力必须由模型外部的系统提供。
二、从模型到 Agent，需要跨越五层工程
Agent 不是单一技术，而是一组工程层的组合。
| 层次 | 解决的问题 | 典型内容 |
|---|---|---|
| Prompt | 这一轮应该怎么做 | 角色、指令、输出格式 |
| Context | 这一轮应该看到什么 | 检索、压缩、隔离、上下文选择 |
| Tools | 如何接触和改变外部世界 | 搜索、代码、浏览器、数据库、API |
| Loop | 如何持续推进任务 | 计划、行动、观察、验证、重试 |
| Harness | 如何让整个过程可靠运行 | 权限、沙箱、预算、日志、检查点、恢复 |
Prompt Engineering 关注的是：
应该怎样告诉模型？
Context Engineering 关注的是：
模型此刻应该看见什么？
Tool Engineering 关注的是：
模型可以做什么，以及工具应该返回什么？
Loop Engineering 关注的是：
下一步由什么信号触发，何时继续，何时停止？
Harness Engineering 关注的是：
当模型犯错、进程崩溃、上下文耗尽或成本失控时，系统如何兜底？
真正的 Agent 产品，不是在这五层中任选一层优化，而是让它们形成闭环。
三、Loop 很简单，困难的是环路外围
几乎所有 Agent 最终都会收敛到类似结构：
目标
↓
模型判断下一步
↓
调用工具
↓
读取结果
↓
判断是否完成
↓
未完成则继续代码层面的 while 循环并不复杂。
真正决定 Agent 是否可靠的，是循环外围的控制机制：
- 什么叫完成？
- 谁来判断完成？
- 一次最多执行多少步？
- 最多消耗多少 Token 或预算？
- 工具失败后应该重试、切换还是停止？
- 连续重复相同行为时，如何识别卡死？
- 人类介入后，是否能够从原状态继续？
- 模型上下文耗尽后，下一个会话如何接班？
因此，更准确的表达不是“Agent 是一个循环”，而是：
Agent 是一个受到目标、状态、预算和验证共同约束的循环。
没有约束的循环不是自主性，而是失控。
四、长任务的本质，不是“思考更久”，而是“换班不失忆”
很多人把 Long-running Agent 理解成让模型连续运行几个小时。
这只是表面。
Anthropic 在长任务 Agent 的实践中发现，复杂任务很难在单个上下文窗口内完成。新的上下文会话开始时，模型并不知道上一轮发生了什么，这更像一个由多班工程师轮流接手的项目：每一位新工程师上班时，都失去了上一班的记忆。
因此，长任务真正要解决的不是“让一个模型永远不下班”，而是：
让每一个失忆的新模型，都能迅速知道目标是什么、已经做了什么、下一步做什么，以及怎样才算完成。
这是一套交接制度，而不只是推理能力。
一个可靠的交接至少需要四类工件
| 工件 | 回答的问题 |
|---|---|
goal.md / 任务规格 | 最终到底要交付什么 |
feature-list.json | 哪些完成，哪些尚未完成 |
progress.md / Session Log | 刚刚发生了什么 |
| Git / Checkpoint | 当前有哪些可恢复的工作状态 |
Anthropic 的实验采用了两个不同角色：
- Initializer Agent：第一次运行时建立任务环境、功能列表、启动脚本和初始状态；
- Coding Agent：后续每次只推进一个增量，并在退出前留下清晰的进度和代码提交。
这套方法最有价值的启发不是“使用两个 Agent”，而是：
用外部工件传递状态，而不是依赖模型记住历史。
上下文摘要只能帮助理解。
结构化工件才能支持接班。
五、构建长任务 Agent，需要先建立三份合同
从产品架构角度看，一个可靠 Agent 至少需要三份明确的合同。
1. Goal Contract：目标合同
目标合同回答：
- 要解决什么问题？
- 最终交付物是什么？
- 哪些内容不在范围内？
- 有哪些约束条件？
- 谁拥有最终决策权？
“帮我做一个网站”不是目标合同。
“完成一个支持邮箱登录、密码重置和权限隔离的 Web 应用，并通过指定的端到端测试”才接近目标合同。
目标必须可执行，而不是只有方向感。
2. State Contract：状态合同
状态合同回答：
- 当前进展存在哪里？
- 哪些数据是事实来源？
- 哪些内容只是临时推理？
- 进程重启后从哪里恢复？
- 多个 Agent 如何避免覆盖彼此的工作？
对话记录不应该是唯一的状态来源。
OpenAI 在 Harness Engineering 实践中，将代码仓库和结构化文档作为 system of record。简短的 AGENTS.md 只负责提供地图，再指向架构、产品规格、执行计划和可靠性文档，而不是把所有规则塞进一个巨大提示词。
这背后的产品原则是：
对话可以丢，状态不能丢。
3. Verification Contract：验证合同
验证合同回答：
- 什么叫做完成？
- 使用什么证据证明完成？
- 谁来执行验证？
- 模型是否有权修改验证标准？
- 失败后如何反馈到下一轮？
模型天然倾向于把“我已经做了”误认为“这件事已经可用”。
因此，完成标准必须外置：
- 测试是否通过；
- 数据是否符合阈值；
- 页面是否能走通真实用户路径；
- 文件是否按要求生成；
- 审批是否完成；
- 关键字段是否齐全。
Anthropic 在长任务实验中明确限制 Agent：不能通过删除或修改测试来制造通过结果。
这是一个非常重要的工程判断：
Agent 不应同时拥有执行任务、定义成功和宣布成功的全部权力。
生成与评判必须适度分离。
六、Memory 不是“记住更多”，而是维持工作连续性
很多产品把 Agent Memory 理解成：
- 记住用户姓名；
- 记住用户偏好；
- 将历史对话写入向量数据库；
- 下次对话时检索出来。
这些功能有价值，但不是长任务 Memory 的核心。
长程 Agent 更需要的是四种不同的记忆：
| 记忆类型 | 主要内容 | 典型载体 |
|---|---|---|
| Working Memory | 当前正在思考什么 | 上下文窗口 |
| Episodic Memory | 这次任务发生过什么 | 事件日志、进度记录 |
| Semantic Memory | 长期稳定事实 | 文档库、知识库 |
| Procedural Memory | 过去验证过的工作方法 | Skill、脚本、Playbook |
对长任务来说，最先需要建设的通常不是复杂向量数据库，而是：
- 任务状态；
- 决策记录；
- 错误记录；
- 已验证结果；
- 下一步计划；
- 可恢复检查点。
因此，Memory 更准确的定义是：
让未来的执行者，可以基于过去的有效状态继续工作。
记忆不是越多越好。
未经治理的错误记忆、过期规则和偶然经验，可能比失忆更危险。
七、Harness 不是框架，而是 Agent 的控制系统
Harness 经常被翻译成“脚手架”或“执行框架”，但这容易低估它的重要性。
更准确地说，Harness 是 Agent 外部的控制系统。
它负责处理模型不擅长、也不应该独立处理的问题：
- 工具权限；
- 沙箱隔离；
- 执行预算；
- 超时控制；
- 重试与熔断；
- 日志与审计；
- 状态保存；
- 人工审批；
- Checkpoint；
- 进程恢复；
- 质量评估。
Anthropic 在 Managed Agents 架构中，将系统拆分为三个可替换部分：
- Session：记录完整过程的 append-only 日志；
- Harness：负责调用模型并路由工具的控制环；
- Sandbox：模型运行代码和修改文件的执行环境。
这个拆分意味着：
- 模型可以替换；
- 沙箱可以销毁重建；
- Harness 可以持续演进；
- 任务状态仍然能够保留。
因此，真正稳定的 Agent 产品不应该与某个模型深度绑定。
模型应该是可替换的 Brain，任务状态和执行协议才是长期资产。
八、工具数量不是能力，工具可理解性才是能力
很多 Agent 产品通过接入更多 MCP、API 和工具来展示能力。
但工具越多，模型的选择难度往往越高。
Anthropic 在工具设计实践中指出，更多工具并不必然带来更好结果。工具需要具备清晰的功能边界、合理的命名空间、有意义的返回内容，并控制上下文消耗。
这意味着 Agent 工具不能只是把传统 API 原样暴露给模型。
传统 API 是给确定性程序调用的。
Agent 工具是给非确定性模型理解和选择的。
一个好的 Agent 工具应该：
- 对应清晰的用户意图；
- 减少不必要的中间步骤；
- 返回足够但不过量的信息；
- 明确失败原因；
- 对副作用操作支持幂等；
- 让模型能够判断下一步；
- 避免多个高度相似的工具产生歧义。
工具设计的目标不是暴露更多能力，而是减少 Agent 的决策熵。
九、多 Agent 不是起点，而是单 Agent 系统成熟后的结果
当 Agent 效果不好时，很多团队会立即拆出：
- Planner；
- Worker；
- Researcher；
- Critic；
- Judge；
- Supervisor。
这会让架构看起来更完整，却不一定让任务更可靠。
如果一个单 Agent 系统还没有：
- 明确的目标合同；
- 外置的任务状态；
- 可执行的完成标准；
- 稳定的工具；
- 失败恢复机制；
- 可观测的执行轨迹；
那么增加 Agent 数量，通常只是在放大沟通成本和错误传播。
Anthropic 早期的 Agent 工程总结也强调，效果较好的系统往往来自简单、可组合的模式，而不是一开始就引入复杂框架。
多 Agent 真正适合的场景是：
- 任务可以自然并行；
- 不同角色需要不同工具权限；
- 生成和评判需要隔离；
- 不同模型在不同子任务上具有明显优势；
- 单一上下文无法容纳全部信息。
因此，正确顺序应该是：
先让一个 Agent 可控地完成工作，再让多个 Agent 协同完成工作。
十、Agent 产品的界面，也应该从聊天转向任务状态
当 Agent 的工作单位从“一次回复”变成“一条工作环路”，产品界面也必须改变。
传统聊天界面主要呈现：
- 用户说了什么；
- 模型回答了什么。
但长任务产品真正需要呈现的是：
- 当前目标；
- 任务计划；
- 正在执行的步骤；
- 已完成事项；
- 阻塞原因；
- 工具调用；
- 成本与耗时；
- 产生的工件；
- 验证结果；
- 等待用户决策的节点。
因此：
产品主界面应围绕任务状态设计，而不是继续堆聊天气泡。
聊天可以是输入方式。
但聊天不应该继续承担任务管理、状态展示、异常处理和结果验收的全部职责。
未来成熟的 Agent 产品，更像：
- 项目控制台；
- 任务运行时；
- 工件工作区；
- 审批与异常中心；
- 可恢复的执行记录。
而不是一个更长的聊天窗口。
十一、Agent 产品真正的护城河，也正在发生变化
模型会持续升级。
工具协议会逐渐标准化。
基础 Agent Loop 也会成为公共能力。
因此，仅靠“接入一个更强模型”很难构成长期壁垒。
更值得积累的是以下资产：
1. 任务定义能力
把模糊需求转化为目标、约束、步骤和完成标准。
2. 工作流数据
知道真实任务在哪一步失败、为什么失败，以及什么策略更有效。
3. 验证系统
能够判断结果是否真的可用，而不只是看起来合理。
Agent Eval 之所以重要，是因为多轮 Agent 会持续修改环境，早期错误也可能在后续步骤中被放大。
4. 领域工件
行业模板、业务规则、检查清单、数据结构和交付规范。
5. 恢复与治理能力
权限、审计、预算、人工介入、版本和回滚。
这些资产共同构成的不是一个更大的 Prompt，而是一套领域运行系统。
未来 Agent 产品的竞争，不只是模型竞争，而是任务运行系统之间的竞争。
十二、对创业者的三个判断
判断一：不要从“做一个万能 Agent”开始
万能 Agent 缺少明确完成标准，也难以形成稳定评估。
应先选择：
- 任务边界清楚；
- 输入相对标准；
- 工具可以控制；
- 结果可以验证；
- 失败成本可接受；
的场景。
先做可验证的窄任务，而不是不可验证的宽能力。
判断二：不要只展示 Agent 会做什么
用户最终关心的不是：
- 调用了多少工具；
- 思考了多少步；
- 运行了多少 Agent；
- 使用了多长上下文。
用户关心的是：
- 是否完成；
- 是否可靠；
- 是否可以复查；
- 出错后是否能恢复；
- 是否节省了真实工作时间。
因此，Agent 产品应从“能力展示”转向“结果交付”。
判断三：人类不会立刻退出工作环路
METR 的 Time Horizon 研究显示，模型能够处理的任务长度正在增长，但其指标主要基于边界清晰、可以相对客观评分的软件、机器学习和安全任务。真实工作往往包含隐性背景、跨团队协作和难以算法化的成功标准，因此不能把更长的任务时间直接等同于完整岗位自动化。
人的角色会发生变化：
过去，人主要负责执行。
未来，人会更多负责：
- 定义目标；
- 设定边界；
- 提供关键背景；
- 处理例外；
- 判断取舍；
- 承担责任。
Agent 扩大的是执行带宽，而不是自动消除人类判断。
十三、一个最小可行的 Agent 工作环路
对于正在构建 Agent 产品的团队，可以先从以下结构开始：
用户意图
↓
Goal Contract
目标、范围、约束、交付物
↓
Plan
拆分为可验证的工作单元
↓
Agent Loop
计划 → 行动 → 观察 → 修正
↓
External State
进度、工件、日志、检查点
↓
Evaluator
测试、规则、Judge、人工审批
↓
未通过 ─────→ 回到 Loop
↓
通过
↓
Final Artifact
可交付、可复查、可继续使用的结果最小实现不需要复杂的多 Agent 平台。
但至少应该具备：
- 明确的目标文件；
- 结构化任务列表；
- 外置进度状态；
- 工具错误反馈；
- 最大步数与预算；
- 独立完成标准；
- Checkpoint 与恢复；
- 完整执行日志；
- 人工介入节点；
- 最终工件，而不只是最终回答。
结语：Agent 的未来，不是模型一直思考
Agent 产品最容易浪费资源的地方，是在错误的层反复优化：
- 反复修改 System Prompt，却没有稳定状态；
- 不断增加工具，却没有控制上下文；
- 直接引入多 Agent，却没有明确目标；
- 追求更长上下文，却没有交接机制；
- 让模型宣布完成，却没有独立验证；
- 强调自主执行，却没有预算、权限和恢复。
真正有价值的路径恰好相反：
- 先定义什么叫完成；
- 再把任务拆成可验证单元；
- 把状态放到模型之外；
- 用 Loop 持续推进；
- 用 Evaluator 阻止虚假完成；
- 用 Harness 提供权限、预算、观测和恢复；
- 最后再扩展长期记忆和多 Agent 协作。
模型不是 Agent 的全部。
模型只是每一轮负责判断下一步的推理组件。
真正让它成为 Agent 的，是那条能够跨越多次工具调用、多次上下文切换和多次失败，仍然持续朝目标前进的工作环路。
模型提供智力。
工具提供行动。
状态提供连续性。
验证提供可信度。
Harness 提供控制。
Loop 把它们组织成工作。
所以，判断一个 Agent 是否真正成立，不要只看它第一次回答得多聪明。
要看它跨过第三个上下文窗口、第五十次工具调用和第一次进程崩溃之后，是否仍然知道：
目标是什么。
已经做到哪里。
下一步应该做什么。
怎样才算真正完成。
参考资料
- Simon Willison：Agent 的“工具调用环路”定义
- Anthropic：Effective harnesses for long-running agents
- OpenAI：Harness engineering
- Anthropic：Scaling Managed Agents
- Anthropic：Writing effective tools for agents
- Anthropic：Demystifying evals for AI agents
- Anthropic：Building effective agents
- METR：Task-Completion Time Horizons of Frontier AI Models