从调教提示词到搭 Harness 支架：为什么你的 Coding Agent 总是失控、失忆与迷航？

在当下席卷开发者社区的“结对编程智能体”（Coding Agent）浪潮中，许多工程团队正经历一种普遍的挫败感：哪怕接入了推理能力极其强悍的旗舰模型，甚至精心打磨了成百上千字的 System Prompt，一旦让 Agent 面对真实的大型工程，它依然会频繁出现令开发者崩溃的症状——越权篡改无关代码、陷入原地打转的死循环、修好了 Bug 却把生产环境断了网、跑了十几分钟后彻底遗忘初衷。

当智能体表现糟糕时，许多人的第一反应依然是去“改提示词”：把限制写得再凶一点，把格式规定得再死一点。然而，残酷的生产实践告诉我们：这从来不是大模型智力不足的缺陷，而是我们根本没有为它搭建起一套成熟的工程运行支架（Harness）。

从简单的问答 Bot 到真正能持续自主推进交付的 Coding Agent，AI 工程范式正悄然完成三次深刻的代际演化。本文将为你系统拆解这套由浅入深的系统工程体系。

一、范式演进三部曲：层层外延的系统拓扑

Prompt Engineering、Context Engineering 与 Harness Engineering 不是非此即彼的替代关系，而是同一套 AI 自主系统在不同交付要求下的三个抽象层次。

• Prompt Engineering（提示词工程）：解决的是任务表达问题——“你如何把指令说得清晰、准确、有条理”；
• Context Engineering（上下文工程）：解决的是信息编排问题——“在模型进行每一步决策的毫秒级瞬间，它的视野窗口里能看到什么”；
• Harness Engineering（运行支架工程）：解决的是运行闭环问题——“模型在什么样的边界约束、执行环境、反馈回路与记录系统中持续推进任务”。

当我们的目标从“回答一道题”升级为“稳定交付一段生产工作流”，工程的重心就必须由内向外发生刚性转移。

二、1.0 提示词工程：把任务说清楚的极限边界

作为绝大多数开发者接触大模型的第一站，Prompt Engineering 的价值在于建立统一的输入规范。通过身份定义（Persona）、少样本举例（Few-shot）、思维链引导（Chain-of-Thought）以及思考-行动循环（ReAct），我们能够显著压低由于大模型生成随机性带来的发散。

但在面对复杂的工程开发时，提示词工程的物理天花板非常明显：

1. 它无法凭空给模型注入私域系统的上下文：即使你把提示词写得天花乱坠，大模型依然不可能凭空预知你公司内部微服务接口的字段定义与老系统的特定 Bug。

2. 它无法提供真实的系统权限与执行环境：写在提示词里的“请保证编译通过”，对于模型而言只是一串语义标记，它根本无法验证编译命令到底有没有执行、退出码是否为零。

3. 它不能代替错误恢复与状态持久化机制：一旦长对话超出上下文窗口被截断，写在首轮的警告往往会被模型彻底淡忘。

因此，单靠“写好一段 Prompt”，绝不可能驱动一个能自主处理半小时任务的 Coding Agent。

三、2.0 上下文工程：视野编排的精细化进阶

当任务演进为多步执行时，系统重心顺理成章地迁移到上下文工程（Context Engineering）。上下文不仅指初始指令，还包含历史对话、工具定义、工具执行返回、检索召回的知识碎片以及项目实时状态。

在上下文工程的演化过程中，有三个关键维度构成了它的主干：

1. 检索增强（RAG 与代码定向检索的分野）

面对超出上下文窗口的大型资料，RAG 提供了语义相关的片段召回。但很多在代码场景下开发 Agent 的团队踩过同一个大坑：盲目对整个代码仓库做文本 Embedding 向量化，再通过余弦相似度检索相关代码。

工程经验警示： 软件调试与代码重构不是常规的语义问答。代码定位高度依赖确切的类名、方法名、函数调用链、错误堆栈中的精确行号以及 Git Commit 记录。在这种强结构化场景中，直接赋予 Agent 原生文件系统的 Grep、Glob 与行级读取工具，其召回精度往往数倍优于模糊的向量语义检索。

2. 工具抽象与协议解耦（从正则匹配到 MCP）

为了打破“缸中之脑”的局限，工具调用经历了从脆弱的字符串正则匹配，到标准 Function Calling，再到跨平台 Model Context Protocol (MCP) 协议的跃升。

但工具并非越多越好。过多未使用的工具描述不仅会白白侵占宝贵的上下文窗口，还会显著增加大模型的工具选择困惑度。因此，优秀的现代 Agent 系统往往倾向于只暴露一小组核心基础原语（如 Read、Write、Grep、Bash），其余具体业务能力则封装为按需挂载的扩展技能（Skills）。

3. 上下文工程为何依然做不稳长任务？

上下文工程解决了“给模型看什么”，但它依然无法回答以下致命的工程问题： - 模型会不会一不小心调用高危工具破坏系统？ - 代码改完后，它如何证明改动是正确的？ - 报错发生后，它应当依据什么标准决定是重试、回滚还是暂停向人类求助？

这些痛点，正是催生 Harness Engineering 的根本催化剂。

四、3.0 Harness Engineering：搭建能自愈、可追溯的生产支架

何谓 Harness（挽具/支架）？我们可以打一个形象的比方：如果把一个能力卓越的 AI 模型比作一位刚入职的高级工程师，那么 Prompt 只是你随口指派的需求描述，Context 是你扔给他的交接文档，而 Harness 则是整个公司的技术基建、开发规范、门禁系统与研发流程。

一位优秀的工程师之所以能稳定交付，靠的绝不仅仅是他脑子里的算法知识，更是因为有明确的代码审查规则、完备的 CI/CD 自动化流水线、可观测日志报警以及严禁越权的线上操作权限。

在工程落地层面，一套完整的 Harness 支架由以下四大核心立柱支撑：

1. 显式的规则边界与完成条件

让 Agent 知道“什么时候必须停下来”和“哪些红线坚决不能碰”，远比让它知道“做什么”更关键。在任务开始前，支架必须明确注入刚性门禁： - 哪些路径（如 .git/、密码文件、核心配置）严禁写操作； - 单个 Bug 修复如果连续报错超过 3 轮，必须立即阻断并上报错误拓扑，禁止自杀式盲目尝试； - 明确定义成功的客观验收指标（如特定测试用例 Exit Code = 0）。

2. 可观测的确定性反馈回路

没有反馈回路的 Agent 就如同蒙眼狂奔。改完一段代码后如果不能立即获得机器的确定性回传，它就只能在臆想中确认自己已经修好。成熟的 Harness 必须为 Agent 接入： - 实时编译与 AST 静态语法检查； - 单元测试与集成测试运行器； - 类型系统与 Lint 告警日志。

只有让客观的终端输出直接重回 Agent 的上下文视野，它才能形成有效的自我反思与纠错循环。

3. 渐进式披露的外部记录系统（External Memory）

上下文窗口再长也是易失性的内存。在耗时数十步的长程复杂工程中，如果不将中间关键决策外部化，Agent 必然会在信息冲刷中逐渐“失忆”。

聪明的架构设计是将记忆外置： - 用结构化的 docs/ 目录记录需求架构与方案设计； - 强制 Agent 在写代码前先沉淀设计文档，遇到分歧先查验已有文档； - 用 Git 版本历史充当天然的代码记忆，鼓励原子化的小步提交与快速回滚。

五、实战对比：从失控调试到自愈排障的代码闭环

为了直观呈现 Harness 支架对 Agent 表现的质变提升，我们在页面包的 practice/ 目录下提供了一个可运行的轻量级闭环模拟器。你可以直接在终端中运行它：

python3 practice/harness_pipeline_demo.py

终端将清晰呈现具备边界守护、反馈回路与决策持久化机制的运行状态：

=== Harness Engineering 最小可运行闭环演示 ===
[Harness Gate] 拦截非法工具调用: rm_rf_root
[Harness Feedback] 运行语法与 AST 静态检查...
[Harness Ledger] 写入步骤存根: Step 1 -> compile_check

当前外部记忆账本已保存 1 条不可逆事实。
================================================

三大工程范式的全维度要素对比

六、总结：Agent 时代的开发者新角色

当基础大模型的通识推理能力逐渐逼近临界点，盲目比拼“谁会念更好的提示词咒语”正在迅速失去意义。

在全新的智能体软件工程范式下，开发者的角色正在发生根本性的迁移：我们不再是那个逐行敲打代码的工匠，也不再是苦思冥想 Prompt 措辞的催眠师，而是成长为系统级的架构设计师——负责为 AI 智能体设计坚固的边界规则，接入敏感可靠的反馈神经，铺设条理清晰的外部知识与版本记录地图。

把舞台与支架（Harness）搭牢固，剩下的奇迹，交给大模型去尽情施展。