Agent 工程：Prompt、Context、Harness 与 Loop

原创

让模型回答一个问题，和让它连续修改文件、检查结果，是两种不同的使用方式。后者需要我们组织指令、资料、工具和执行过程。这里用“让 Agent 修改一篇博客”这个例子，理解 Prompt、Context、Harness 和 Agent Loop 各自负责什么。

部分	关注的问题	修改博客时的例子
Prompt	要做什么，怎样才算做好	保留原意，补一个例子，使用简洁中文
Context	这一轮需要看到什么	原文、写作规范、两篇风格样本
Harness	用什么工具做，受到什么约束	文件读写、目录权限、Markdown 检查
Agent Loop	执行后如何继续或结束	修改 → 检查 → 根据结果修正或交付

这个顺序是为了方便理解，不代表四代互相替代的技术。Prompt 是上下文的一部分，Loop 则通常是 Harness 中组织执行的核心机制。

1. Prompt 工程：把任务说明白

Prompt 工程关注如何组织给模型的指令。比如只说“帮我优化博客”，模型并不知道我们希望补充原理、删除重复，还是调整排版。

可以把要求写具体：

请修改 InfoNCE-Loss.md：
- 解释正样本和负样本的含义；
- 补充一个可以手算的例子；
- 使用简洁中文，不扩写无关背景；
- 保留原有标题和日期；
- 完成后说明修改内容及检查结果。

这段指令说明了任务、范围和交付要求。如果仍然出现偏差，再根据具体问题补充规则或示例。Prompt 的价值在于表达准确，不在于写得长，也不必每次都加一大段角色设定。

已有的 ChatGPT 论文写作 Prompt 可以作为模板参考；需要反复执行的流程，则可以整理成 从零开始学习 Codex Skill 中介绍的 Skill。

2. 上下文工程：给这一轮需要的信息

Context 是模型本轮推理时实际能看到的信息，包括指令、历史对话、工具说明，以及读取到的文件和工具结果。上下文工程关注这些信息如何选择、组织和更新。上下文工程说明

例如，要求“符合我的博客风格”，只写这句话还不够，需要让模型看到写作规范和代表性文章。针对这次修改，可以提供：

• 当前目标和限制：修改哪篇文章，哪些内容需要保留。
• 必要资料：原文、写作规范、两篇同类型文章。
• 当前进度：已经修改了什么，检查发现了什么，接下来还缺什么。

文件存在磁盘上，不等于模型已经读过；之前读过，也不保证原文在后续每一轮都完整保留。所以需要按任务读取相关内容，长任务中还可以将关键决策、未完成事项和文件位置写成简短记录。

比如一次检查输出了很长的日志，下一轮通常更需要“哪个文件、哪一处、什么错误”，而不是一直保留整段重复日志。压缩时仍要保留重要限制和错误细节，避免把继续工作需要的信息一起删掉。

3. Harness 工程：准备工具、环境和约束

Harness 可以理解为让模型实际工作的外围系统。模型提出读取或修改文件的请求，由程序执行工具，再将结果交回模型。权限、运行状态和检查流程也需要由系统管理。

对于修改博客的 Agent，可以这样安排：

能力	具体作用
文件搜索与读取	找到目标文章、规范和风格样本
文件编辑	将修改写入 Markdown
权限控制	限制能修改的目录
检查工具	发现 Front Matter、代码围栏或链接错误

Prompt 中写“不要修改其他目录”属于指令；在文件系统层限制写入目录，才是执行层面的约束。检查工具也需要实际接入执行过程，才能将错误反馈给 Agent。

已有的 Harness engineering 会用分类器评估的例子，进一步说明如何把要求变成验收条件。Harness 的范围也包括文档和工作环境的组织，可以参考 Harness engineering 中的工程实践。

4. Agent Loop：根据执行结果继续工作

有了指令、上下文和工具，还需要把一次次模型调用串起来。Agent Loop 就是这个执行循环：模型根据当前信息决定下一步，程序执行工具，将结果加入上下文，再调用模型。Agent 构建说明

修改博客时，一个简化过程如下：

读取原文和规范
      ↓
模型请求修改文件
      ↓
程序执行编辑，返回结果
      ↓
模型请求检查，程序返回检查结果
      ↓
有错误 → 带着错误信息继续修改
已完成 → 输出修改说明，结束

模型每轮可能请求一个或多个工具，也可能直接回答。循环负责接收这些结果并更新状态，不是让模型脱离外部程序一直自行运行。

停止条件同样需要设计：任务完成就交付；遇到缺少权限或必须由用户决定的问题就暂停；连续失败或达到步数、时间预算时，应说明未完成的原因，避免重复执行同一个无效动作。

这里的检查也有边界：Markdown 格式通过，不代表文章的技术结论一定正确。工具检查与内容核对需要配合，Loop 才能根据有效反馈推进任务。

4.1 从一次任务到持续执行

普通对话本身就能包含多次工具调用。例如“修复这篇博客的格式并验证”，Agent 可以在一次任务中反复修改和检查，不需要专门开启定时循环。

如果希望任务在一轮结束后继续，或者隔一段时间再执行，就需要外层控制。下面以 Claude Code 的交互命令为例，它们输入在 Claude Code 对话框中，不是 Shell 通用命令。例子中的测试脚本、仓库和 PR，需要替换成自己的项目。

4.2 Goal：有明确目标，就继续推进

适合“修复测试直到通过”这类可以持续推进、能够验收的任务。假设项目已经有 npm test 和 npm run lint：

/goal 修复当前项目的代码，使 npm test 和 npm run lint 均以退出码 0 结束。
不得删除、跳过或修改现有测试，不改变公开 API。
每轮报告验证命令和退出码；最多执行 5 轮，仍未完成则停止并说明阻塞原因。

Claude 每轮结束后，独立评估模型会根据对话中的执行证据判断目标是否满足，尚未满足时推动下一轮继续。比如第一次修改后还剩一个失败测试，就带着失败信息继续修复。

输入 /goal 可以查看状态，/goal clear 可以清除目标。这里的“5 轮”是写给执行模型和评估器的停止条件，不是独立的硬性配额开关；/goal 也不会自动扩大工具权限。Goal 文档

4.3 Loop：等待外部变化，隔一会儿再看

适合检查 CI、部署状态或新的 Review 意见。这类任务需要等待外部系统，不必持续重复查询：

/loop 5m 检查当前分支 PR 的 CI 状态。
如果失败，读取失败日志并总结原因；如果仍在运行，简短报告状态。
全部通过或 PR 关闭后，取消这个定时任务。不要修改或推送代码。

5m 表示每 5 分钟检查一次，前提是已经有读取 PR 和 CI 的工具及访问权限。它依赖运行 Claude Code 的进程和会话，不适合作为关闭终端后仍长期运行的服务。

需要手动停止时，可以直接说“取消刚才检查 PR 的定时任务”，并确认取消结果。固定间隔的任务需要取消，不能把按 Esc 当成通用的删除方式。Loop 文档

4.4 Schedule：按计划启动独立任务

适合每天或每周重复执行的工作。例如每天整理仓库变化：

/schedule 每个工作日北京时间上午 9 点，汇总博客仓库自上次成功运行以来合并的 PR。
按新增文章、内容修订、站点配置分类，只在任务结果中输出摘要，不修改文件。
首次运行只查看过去 24 小时。

这个命令会引导确认时间、仓库和任务内容，再保存为云端 Routine。Routine 可以理解为“保存好的任务配置”，每次触发会创建新的执行会话，因此不依赖本机终端一直打开。需要可用的 claude.ai 订阅登录，以及云端能够访问的仓库和环境；本机未提交的文章不会自动出现在云端。

创建后确认任务已保存，检查下次运行时间；不需要时，在 Routine 管理页面停用。相关入口和要求见 Routine 文档。

如果将触发方式改为“新 PR 创建时启动审查”，就属于事件驱动的用法：收到事件后运行一次 Agent Loop，输出结果后结束，再等待下次事件。这类 Proactive 自动化是触发器、任务流程与验证的组合，不需要把它理解成一个新的无限循环命令。

本文由 Yonghui Wang 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Sep 06, 2026 02:57 pm