【Agent开发】从 Prompt 到 Context，再到 Harness：Agent 开发真正难的不是“会调用大模型”

文章目录前言一、从 Prompt Engineering 到 Context Engineering再到 Harness Engineering1.1 Prompt Engineering最早被大家理解的 AI 技能1.2 Context Engineering1.3 Harness Engineering从“给信息”走向“搭环境”二、Harness Engineering 到底在“驾驭”什么2.1 驾驭的不是模型而是模型的行动过程2.2 Harness 像是 Agent 的运行时系统2.3 Harness 最核心的四件事2.3.1 可控Agent 不能想做什么就做什么2.3.2 可验证不能只听 Agent 说“我做完了”2.3.3 可恢复失败要能收敛而不是继续胡编2.3.4 可沉淀不要每次都靠临时调 Prompt2.4 Harness 的目标让 Agent 从“能用”变成“可交付”三、以 Coding Agent 为例如何设计一个最小可用 Harness3.1 先别急着让 Agent 改代码3.2 Context Provider不要把整个仓库一股脑塞进去3.3 Tool Runtime工具可以给但不能无限给3.4 Verifier把“我觉得对”变成“测试证明过”3.5 Reporter最后交付的不是回答而是可 review 的结果3.6 这个最小 Harness 到底长什么样写在文后 个人主页铁皮哥欢迎关注 作者简介28届校招生后端开发/Agent 方向在学 学习内容Java、Python、计算机视觉、大语言模型、Agent开发 专栏内容从零开始的Claude Code零代码生活持续更新中✨不只背八股更想搞懂为什么这样设计前言这两年聊 Agent 开发很多人第一反应还是把 Prompt 写好就行了。这也正常。刚开始用大模型时我们最容易感知到的差异就是同一个问题换一种问法答案质量可能完全不一样。于是大家开始研究怎么写提示词怎么设定角色怎么约束输出格式怎么让模型少跑偏。但我最近越来越觉得Agent 开发真正难的地方已经不在“怎么把 Prompt 写漂亮”了。因为一旦任务从“回答一个问题”变成“完成一件事情”问题的性质就变了。比如让模型解释一段代码Prompt 写好一点确实有用但如果我要做的是一个 Coding Agent让它根据 issue 定位 bug、修改代码、补测试、跑验证、生成 PR 说明那光靠 Prompt 就明显不够了。这时候我们关心的不只是模型会不会说而是它能不能在一个受控的流程里稳定做事该读哪些文件能调用哪些工具失败了怎么恢复改完以后怎么验证哪些操作必须让人确认。这就是我想聊 Harness Engineering 的原因。Harness Engineering 是给 Agent 搭一个真正能干活的工程环境。它不只是让模型回答得更好而是让模型的能力可以被约束、被验证、被复用最后变成一个相对可靠的软件系统。一、从 Prompt Engineering 到 Context Engineering再到 Harness Engineering在讲 Harness Engineering 之前应该先了解了解 AI 工程的发展历程。按时间顺序这几年 AI 工程的发展经过了Prompt Engineering、Context Engineering 和 Harness Engineering三个阶段。一开始我们面对的是“怎么让模型回答得更好”后来变成“怎么让模型拿到正确的信息”再往后问题就变成了“怎么让模型在真实工程环境里稳定做事”。这条线索理清以后Harness Engineering 为什么重要就会自然很多。1.1 Prompt Engineering最早被大家理解的 AI 技能最早大家接触大模型大多是从聊天框开始的。那时候最直接的感受就是同一个模型不同问法效果差别很大。你随便问一句它可能给你一个很泛的回答但如果你把背景、目标、角色、输出格式都说清楚结果就会明显更可用。所以 Prompt Engineering 很快变成了大家最先掌握的一类 AI 技能。比如让模型帮你写接口文档随便一句“帮我写个接口文档”大概率会得到一段看起来完整、但细节不一定靠谱的内容。换成更明确的 Prompt告诉它这是给前端同学看的接口用于用户注册需要包含请求参数、响应结构、错误码和示例并且不要编造不存在的字段结果通常就会好很多。这个阶段的核心其实很简单把任务说清楚让模型更准确地理解你想要什么。但 Prompt Engineering 也有很明显的边界。它更适合提升单次调用的质量却很难保证一个复杂任务的全过程都可靠。比如我们让模型解释一段代码好的 Prompt 确实很有帮助。但如果我们让一个 Agent 去修复后端接口 bug事情就不一样了。它不能只是“知道怎么回答”还要知道应该读哪些文件、怎么定位问题、能不能修改代码、改完要不要补测试、测试失败后怎么处理。这些就不是一句 Prompt 能兜住的了。Prompt Engineering 解决的是“怎么问”和“怎么表达任务”的问题。它很重要但它只是 Agent 开发的入口不是完整答案。1.2 Context Engineering从“怎么问”走向“给什么信息”随着大家开始做 RAG、智能客服、代码助手、数据分析 Agent一个新的问题慢慢暴露出来很多时候模型回答不好并不是因为 Prompt 写得不够漂亮而是因为它根本没有拿到该看的信息。这时候Context Engineering 开始变得重要。如果说 Prompt Engineering 关注的是“怎么把任务说清楚”那 Context Engineering 关注的就是“模型做这个任务时到底应该看到什么”。还是拿后端 bug 修复举例。你只告诉模型“用户注册接口在 email 为空时会报 500请修复”它能做的其实很有限。因为它不知道项目结构不知道参数校验在哪一层不知道错误处理规范是什么也不知道现有测试怎么写。真正有用的上下文可能包括相关 controller、service、validator 代码报错日志接口文档测试文件项目的错误码规范甚至还有最近一次相关提交的 diff。但这里也有一个误区Context Engineering 不是把所有东西一股脑塞给模型。上下文窗口再大也不代表越塞越好。信息太少模型会瞎猜信息太多模型会抓不住重点甚至被无关内容带偏。所以更关键的是在任务的不同阶段给模型刚好需要的上下文。定位问题时可能需要日志和调用链修改代码时需要相关模块和测试文件生成总结时又更需要 diff 和验证结果。Context Engineering 的价值就在于把这些信息组织成模型可以使用的“工作记忆”。所以这一阶段Agent 开发开始从“写好一句 Prompt”走向“设计信息供给系统”。它让模型不再只是凭训练知识回答而是能基于当前任务、当前代码、当前状态来工作。但到这里为止我们解决的主要还是“模型知道什么”的问题。至于它该按什么流程做、能做哪些操作、做错了怎么恢复、结果怎么验证这些问题还没有真正解决。1.3 Harness Engineering从“给信息”走向“搭环境”当 Agent 开始从“回答问题”走向“执行任务”问题就又变了一层。一个真正有用的 Coding Agent不应该只是根据上下文生成一段修改建议。它最好能自己读代码、搜索文件、编辑内容、运行测试、根据错误日志继续修正最后给出一个可以 review 的结果。这时候我们面对的已经不是单纯的模型调用而是一个小型工程系统。模型只是其中的一部分。围绕模型还需要工具、权限、流程、验证、日志、回滚和人工确认机制。这个包住 Agent、约束 Agent、帮助 Agent 完成任务的工程系统就是 Harness Engineering 要关注的东西。我比较喜欢用一个不太严肃但好理解的比喻Prompt 像是你对 Agent 说的话Context 像是你递给它的资料而 Harness更像是你给它安排的工作台、工具箱、操作规程和质检流程。没有 Harness 的 Agent可能很聪明但做事不稳定。它可能能一次性生成很漂亮的代码但不一定会跑测试可能看起来修好了 bug但顺手改了无关文件可能执行命令失败后继续硬编一个结果也可能在高风险操作前没有停下来等人确认。Harness Engineering 要解决的就是这些问题。它不是让模型变得更聪明而是让模型的能力在工程环境里变得更可控、更可验证、更容易复用。比如限制 Agent 只能修改某些目录规定每次改完代码必须运行测试把测试结果重新反馈给模型危险操作必须经过人工确认最终输出必须包含 diff、验证结果和风险说明。到这里Agent 开发的重点就不再只是“怎么让模型回答得好”而是“怎么让模型在系统里可靠地完成任务”。所以这三个阶段可以简单理解成Prompt Engineering让模型听懂任务 Context Engineering让模型拿到正确材料 Harness Engineering让 Agent 在受控环境里完成任务Prompt 仍然重要因为任务必须表达清楚。Context 也仍然重要因为模型必须拿到依据。但如果我们希望 Agent 真的进入代码仓库、工具链和业务系统里干活最终绕不开 Harness Engineering。二、Harness Engineering 到底在“驾驭”什么如果只看名字Harness Engineering 很容易被理解成又一个新概念。但我觉得它真正有意思的地方不在于名字新而在于它把一个问题说透了Agent 的问题很多时候不是模型不够强而是我们没有给它一个适合做事的工程环境。以前我们用大模型更多是在“问答”。用户输入一句话模型返回一段内容中间没有太多状态也没有太多外部影响。答错了大不了重新问。但 Agent 不一样。Agent 一旦开始调用工具、读写文件、执行命令、访问 API它就不只是“生成文本”了而是在影响一个真实系统。这个时候光靠 Prompt 里写一句“请谨慎操作”其实是不够的。Harness Engineering 要驾驭的正是这种从“回答”到“行动”之后带来的复杂性。2.1 驾驭的不是模型而是模型的行动过程Harness 不是在增强模型的智商而是在约束和组织模型的行动。模型本身负责判断、生成、推理Harness 负责决定它在什么环境里做事、能用哪些工具、每一步怎么验证、出错以后怎么收敛。这有点像我们写后端服务。业务代码当然重要但一个服务能不能稳定跑起来靠的不是业务代码本身有多优雅还要看日志、监控、限流、权限、回滚、测试、CI/CD 这些配套设施。Agent 也是一样。一个没有 Harness 的 Agent可能可以一次性生成很漂亮的代码但它不一定知道自己有没有改错文件不一定会主动跑测试也不一定能区分“命令真的执行失败”和“我应该编一个看起来合理的结果”。所以 Harness Engineering 真正关心的不是“这次回答漂不漂亮”而是这个 Agent 的行为能不能被限制执行过程能不能被观察结果能不能被验证失败以后能不能恢复同样的错误下次能不能少发生这些问题才是 Agent 进入真实工程环境以后最难的部分。2.2 Harness 像是 Agent 的运行时系统如果用后端视角看Harness 更像是 Agent 的 runtime。一个裸模型只有输入和输出但一个能干活的 Agent 至少需要一整套运行时能力。它要知道当前任务做到哪一步了要能安全地调用工具要能拿到必要的上下文要能把执行结果记录下来还要能在失败后重新规划。这就不是简单封装一个大模型 API 了。比如我们做一个 Coding Agent它要修复一个后端 bug。用户给它一个 issue它不能直接开始改代码。更合理的过程应该是先理解问题再定位相关文件提出修改计划执行代码变更运行测试根据测试结果继续调整最后生成一份能让人 review 的说明。这里面每一步都需要 Harness 参与。它决定 Agent 能不能读整个仓库还是只能读相关目录能不能执行任意 shell还是只能运行白名单里的测试命令能不能直接提交代码还是只能生成 diff 等待人确认测试失败以后是继续尝试、回滚还是交给人工处理。所以我觉得 Harness 最重要的价值是把 Agent 从一个“会聊天的模型”放进一个“能做事的轨道”里。可以把它理解成这样用户任务 → 任务规划 → 上下文准备 → 工具调用 → 权限控制 → 结果验证 → 失败恢复 / 人工确认 → 最终交付注意这条链路里模型只是其中一环。真正让 Agent 变得可靠的是这条链路本身。2.3 Harness 最核心的四件事如果继续拆下去Harness Engineering 其实一直在解决四类问题可控、可验证、可恢复、可沉淀。这四个词听起来有点抽象但放到工程场景里就很好理解。2.3.1 可控Agent 不能想做什么就做什么Agent 越强越不能完全放养。一个只会回答问题的模型答错了还比较好处理。但一个能执行命令、修改代码、访问系统的 Agent如果没有边界就很危险。比如 Coding Agent 可以读取项目代码但它不应该读取.env里的密钥可以运行测试命令但不应该执行未知脚本可以修改业务代码但不应该顺手改 CI 配置可以生成数据库迁移建议但不应该直接连生产库执行。这些边界不能靠 Prompt 来保证。你在 Prompt 里写“不要做危险操作”它当然可能遵守但这不是工程上的可靠做法。真正可靠的方式是从系统层面限制它能看到什么、能改什么、能调用什么。这也是 Harness 和 Prompt 最大的区别之一。Prompt 是提醒Harness 是约束。2.3.2 可验证不能只听 Agent 说“我做完了”工程里最不可靠的一句话就是“应该没问题”。Agent 也一样。它说“我已经修复了 bug”不代表真的修好了。它说“代码可以运行”也不代表测试通过了。所以 Harness 必须把验证接进流程里。对 Coding Agent 来说验证可能是 formatter、lint、类型检查、单元测试、集成测试、接口契约测试。对数据分析 Agent 来说验证可能是字段校验、SQL 结果检查、异常值检测。对客服 Agent 来说验证可能是回答是否引用了正确知识库是否触碰敏感策略。关键是最终结果不能只靠模型自证。一个比较理想的 Agent 输出不应该是我修复了这个问题。而应该更接近我修改了用户注册接口的参数校验逻辑补充了 email 为空字符串的测试用例已通过相关单元测试没有修改数据库 schema风险点是旧客户端如果依赖原错误码需要额外确认。这两种表达的差异不在文采而在可信度。前者是声明后者是交付。2.3.3 可恢复失败要能收敛而不是继续胡编Agent 做复杂任务时失败其实很正常。工具调用可能失败依赖可能装不上测试可能跑不通代码上下文可能不够模型第一次修改也可能方向错了。问题不在于失败本身而在于失败以后系统怎么处理。没有 Harness 的情况下Agent 很容易出现一种很糟糕的行为前一步明明失败了但它继续往下编最后给出一个看起来完整、实际上没有经过验证的结果。这在工程里是很危险的。Harness 要做的是让失败显式化。命令失败了就把错误日志记录下来测试没过就把失败用例反馈给 Agent连续几次修不好就停止自动尝试交给人工接管高风险修改前必须等待确认。真正可靠的系统不是不失败而是失败后不会失控。这点和后端服务很像。我们不会假设接口永远不超时、消息永远不丢、数据库永远不抖动。我们会设计重试、降级、幂等、补偿和告警。Agent 也需要类似的机制。2.3.4 可沉淀不要每次都靠临时调 Prompt我觉得这是 Harness Engineering 最有价值的一点。很多时候我们发现 Agent 犯错后的第一反应是改 Prompt“下次记得跑测试。”“下次不要改无关文件。”“下次注意错误码规范。”这当然有用但不够稳。更工程化的做法是把这些“下次注意”变成系统机制。Agent 总是忘记跑测试那就不要让“跑不跑测试”变成它的自由选择而是把测试做成强制 gate。Agent 总是改错目录那就限制它的可写范围。Agent 总是输出格式不稳定那就加 schema 校验。Agent 总是违反架构分层那就把规则写进 lint 或架构扫描。Agent 总是在上下文太长时跑偏那就做任务拆分和上下文压缩。这就是 Harness 和普通调参最大的不同。调 Prompt 更像是在对 Agent 说“你以后要小心。”做 Harness 更像是在系统里加了一道门“这个错误以后更难发生。”长期来看Agent 系统真正的进化不应该只靠 Prompt 越写越长而应该靠这些约束、验证和反馈机制不断沉淀。2.4 Harness 的目标让 Agent 从“能用”变成“可交付”很多 Agent demo 看起来都很惊艳因为它们展示的是“模型能做到什么”。但真实工程里我们更关心的是另一件事这个能力能不能稳定交付。一次成功不难难的是十次、百次、放到不同项目里、接入真实工具链以后依然有边界、有验证、有日志、有失败处理。所以 Harness Engineering 其实是在补上 Agent 产品化和工程化之间缺的那一层。它不追求让模型显得更神奇而是让模型少一点玄学多一点工程确定性。对于后端 / Agent 开发者来说这一点尤其重要。因为越到真实业务场景Agent 开发越不像“写 Prompt”越像是在设计一个带有权限、状态、工具、验证和反馈机制的后端系统。也正因为如此我觉得 Harness Engineering 最值得关注的地方不在概念本身而在它背后的工程思维不要只想着让 Agent 这一次做对而是要设计一个环境让它持续更容易做对做错了也更容易被发现、被纠正、被沉淀。三、以 Coding Agent 为例如何设计一个最小可用 Harness前面讲了这么多 Harness如果只停留在概念上其实还是有点虚。所以这一节我想换成一个更具体的例子假设我们要做一个Coding Agent它的任务是帮我们修一个真实后端项目里的 bug。比如 issue 是这样的用户注册接口在 email 为空字符串时返回 500预期应该返回 400并给出明确的参数错误信息。如果只是让大模型回答它可能会告诉我们“应该在参数校验层增加 email 非空判断”。这个回答没错但它离真正完成任务还差很远。因为工程里的“修好了”至少意味着它看过相关代码改了正确的位置补了测试跑过验证并且知道这次改动有没有潜在风险。这就是 Harness 要发挥作用的地方。3.1 先别急着让 Agent 改代码一个常见错误是拿到 issue 后直接把问题丢给模型然后让它开始修改。这看起来很快但很容易失控。因为 Agent 一开始并不知道项目结构也不知道参数校验逻辑在哪一层。它可能改 controller也可能改 service甚至可能为了让测试通过顺手改掉全局异常处理。最后代码看起来能跑但改动范围已经偏了。所以一个最小可用的 Harness第一步应该不是“执行”而是“规划”。Agent 需要先输出一份简短计划说明它准备怎么定位问题、可能要看哪些文件、预计改哪里、准备怎么验证。这个计划不需要写得很长但必须让人看得出它不是在盲改。比如Plan: 1. 搜索注册接口入口定位 controller 和参数校验逻辑 2. 查看当前 email 字段的校验方式 3. 补充 email 为空字符串的测试用例 4. 修改参数校验逻辑使其返回 400 5. 运行相关测试确认没有影响正常注册流程这一步的重点是让 Agent 进入一个明确轨道。没有这一步Agent 很容易变成“想到哪改到哪”。有了这一步后面的工具调用、上下文补充、验证流程才有依据。3.2 Context Provider不要把整个仓库一股脑塞进去确定计划之后下一步是给 Agent 准备上下文。这里很容易走向另一个极端既然上下文重要那干脆把整个项目都塞给模型。但这通常不是好办法。一个真实后端项目里controller、service、dao、middleware、config、test、migration 全都塞进去不但浪费上下文窗口还会让模型抓不住重点。Context Provider 要做的不是“给最多的信息”而是“按阶段给刚好够用的信息”。在这个 bug 修复场景里第一轮上下文可以只给 issue、项目目录、注册接口相关文件路径和错误日志。等 Agent 判断可能问题在参数校验层再补充 validator、DTO、全局异常处理和相关测试文件。也就是说上下文应该是逐步展开的。Issue ↓ 搜索相关路由和接口入口 ↓ 读取 controller / DTO / validator ↓ 读取错误处理逻辑 ↓ 读取已有测试 ↓ 根据修改结果补充 diff 和测试输出这样做有两个好处。一是减少无关信息干扰。二是每一轮上下文都和当前动作绑定Agent 更不容易在一堆文件里迷路。这也是为什么我觉得 Context Engineering 应该被放进 Harness 里看。上下文本身不是目的它是为了服务整个执行流程。3.3 Tool Runtime工具可以给但不能无限给Coding Agent 真正开始像 Agent是从它能调用工具开始的。它可以搜索代码、读取文件、编辑文件、查看 git diff、运行测试。没有这些能力它最多只是一个代码建议器有了这些能力它才有机会完成一条工程链路。但工具不是给得越多越好。一个最小 Harness 里工具权限应该尽量收窄。比如这个 bug 修复任务只需要允许 Agent 做这些事允许 - 读取项目代码 - 搜索符号和关键词 - 修改 src / test 目录下的相关文件 - 查看 git diff - 运行指定测试命令 禁止 - 读取 .env、密钥文件 - 访问生产数据库 - 执行未知 shell 脚本 - 修改 CI 配置 - 直接 push 到远程分支这不是不信任模型而是正常的工程边界。我们写后端接口时也不会让一个普通业务接口拥有所有数据库权限。Agent 也是一样它能做的事情越多权限越应该被设计清楚。更重要的是所有工具调用都应该被记录下来。Agent 读了哪些文件执行了哪些命令改了哪些地方测试结果是什么这些都应该进入日志。因为一旦结果不对我们需要知道问题发生在哪一步而不是只看到一句“我已经完成”。3.4 Verifier把“我觉得对”变成“测试证明过”Coding Agent 最容易制造幻觉的地方不是写代码而是解释自己写的代码。它可能非常自信地说“已经修复”但实际上测试没跑或者测试失败了它却继续生成一段看起来合理的总结。所以 Harness 里必须有 Verifier。Verifier 的作用是把工程里的验证手段接进流程。对这个后端 bug 来说至少应该包含三类验证。第一类是格式和静态检查比如 formatter、lint、类型检查。它们能先挡掉一部分低级错误。第二类是相关测试。既要跑新增的 email 空字符串测试也要跑用户注册相关的原有测试避免只修了一个 case却破坏了正常流程。第三类是结果检查。比如确认接口现在返回的是 400而不是把 500 改成了另一个错误确认错误信息符合项目规范确认没有修改数据库 schema 或无关模块。一个简单的流程可以是修改代码 ↓ 运行 formatter / lint ↓ 运行相关单元测试 ↓ 运行注册接口集成测试 ↓ 失败把日志反馈给 Agent重新规划 ↓ 通过进入结果汇总这里最关键的是测试失败不能被静默吞掉。失败日志应该成为下一轮上下文重新交给 Agent 分析。如果连续几次失败就不要继续让它盲试而是停止自动执行交给人类接管。这一步其实就是把后端系统里的“失败处理”搬到了 Agent 流程里。Agent 不需要保证每次都一次成功但它必须在失败时暴露问题而不是假装成功。3.5 Reporter最后交付的不是回答而是可 review 的结果很多 Agent demo 到最后都会输出一段自然语言总结。这个总结当然有用但如果只写“我修复了问题”价值很低。对 Coding Agent 来说最终交付物应该更像一个 PR Summary而不是聊天回复。它至少应该包含Change Summary: - 修改了哪些文件 - 修复了什么问题 - 新增或调整了哪些测试 Validation: - 执行了哪些命令 - 哪些测试通过 - 哪些测试没有运行原因是什么 Risk: - 是否修改数据库 schema - 是否影响旧接口行为 - 是否存在需要人工确认的地方比如这个 case理想输出可能是Change Summary: - 在用户注册参数校验中增加 email 空字符串判断 - 保持原有错误响应结构不变 - 新增 email 为空字符串时返回 400 的测试用例 Validation: - npm run test:user passed - npm run lint passed Risk: - 未修改数据库 schema - 未修改注册流程以外的模块 - 需要确认错误信息文案是否符合前端展示规范这类输出的意义在于它把 Agent 的工作变成了可以 review 的工程结果。人类 reviewer 不需要重新猜 Agent 做了什么而是可以直接看 diff、看测试、看风险点。即使最后不接受这次改动整个过程也有记录可以复盘。3.6 这个最小 Harness 到底长什么样把上面几部分合起来一个最小可用的 Coding Agent Harness 大概是这样输入Issue 仓库路径 允许的测试命令 ↓ Planner先生成修复计划 ↓ Context Provider按阶段提供相关代码和日志 ↓ Tool Runtime在受限权限下读写文件、执行命令 ↓ Verifier运行检查和测试失败则反馈给 Agent ↓ Reporter生成 diff、测试结果、风险说明和 PR Summary在这条链路里Prompt 负责表达任务Context 负责提供材料工具负责执行动作Verifier 负责验证结果Reporter 负责交付信息。而 Harness 要做的就是把这些东西组织起来让 Agent 不再靠自由发挥完成任务。有了这套东西Agent 才开始从“能生成代码”往“能参与工程协作”靠近。写在文后期待您的一键三连如果有什么问题或建议欢迎在评论区交流