AI Coding 不只靠 Prompt：Agent 工程闭环如何接入 DevOps

AI Coding 正在从提示词技巧，走向可验证、可回滚、可自修复的 DevOps 闭环。
原文链接：AI 小老六

过去两年，AI Coding 的新词来得很密：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering。名字一路翻新，底层变化却没那么玄：模型从一次性问答，慢慢被推进到能读项目、能调工具、能被测试约束的工程系统里。

如果只看宣传口径，这些词都像新范式。把链路拆开看，它们更像软件工程旧能力在 Agent 语境下重新排了一次座次。DevOps、CI/CD、容器化、反馈控制没有退场，只是执行者从人和脚本，换成了大模型与运行时。

能力轴：Agent 从会表达走向会闭环

先看一张重画后的结构图。四个阶段并不是彼此替代，而是在不断补齐 Agent 完成研发任务所需的能力。

图：Agent 从表达、知识、行动，走向可验证的自修复闭环

这条线索里，Prompt 解决“怎么表达意图”，Context 解决“模型知道什么”，Harness 解决“模型能不能动手”，Loop 解决“动手后如何靠反馈修正”。越往后，主角越不是模型单点能力，而是模型外面那套工程约束。

Prompt Engineering：把意图写进输入，但写不出项目全貌

Prompt Engineering 的起点很自然：既然模型靠输入驱动，那就把输入写得更清楚。角色设定、任务说明、约束条件、输出格式、Few-shot 示例、Chain of Thought，这些方法确实能提升一次性回答的质量。

典型链路很短：

User → Prompt → LLM → Result

问题也出在“短”。Prompt 可以告诉模型“怎么做”，却很难承载复杂项目的全部背景。于是它越写越长，从几百 token 膨胀到几千甚至上万 token，最后变成一份塞满禁令、角色、格式和例子的临时说明书。

这种方式适合清晰、边界小、上下文稳定的任务。一旦任务依赖代码库结构、业务规则、历史决策和已有接口，Prompt 就开始吃力。输入再漂亮，也挡不住模型缺上下文。

Context Engineering：关键不是会问，而是喂对材料

Context Engineering 的出现，本质上是承认一个现实：很多失败不是模型“不聪明”，而是它不知道项目里已经发生了什么。

这一阶段的重心从 Prompt 模板转向上下文供给：

Context + Prompt → LLM → Result

可用的上下文大致分成三类：

上下文类型	常见内容	解决的问题
项目知识	README、编码规范、架构文档	让模型知道项目怎么组织
业务材料	API Spec、业务流程、示例数据	让模型知道需求边界
动态记忆	Memory、RAG、本地知识库	让模型继承历史经验

图：上下文工程的重点，是把相关、可信、足够新的材料递给模型

这里要看的不是“上下文越长越好”，而是“上下文是否刚好有用”。Context Window、Context Compression、Context Retrieval、Context Ranking、MCP 这些讨论，最后都落到同一件事：在任务发生的那一刻，把相关、可信、足够新的信息递给模型。

Context 把 Agent 从“会接话”推进到“懂项目”。但懂项目仍然不等于能完成研发任务。它还需要进入真实执行环境。

Harness Engineering：让模型接触编译、测试和工具

到了 Harness Engineering，问题从“模型知道什么”变成“模型能做什么”。即使上下文足够，Agent 仍可能乱改文件、不会编译、不跑测试、不看日志，也不会把工具调用结果纳入下一步判断。

图：Harness 为 Agent 提供可执行、可隔离、可验证的行动边界

Harness 提供的是一套行动外壳：

Harness 组件	对应工程能力
Git / Worktree	隔离修改、保留差异、支持回滚
Shell / Docker	提供可执行环境和依赖边界
Build / Test / Lint	用确定性工具验证结果
Deploy / Tools	让 Agent 能调用真实系统
Memory / State	记录任务状态和中间产物

有了 Harness，Agent 的行为从聊天变成一个工程循环：

Observe → Plan → Act → Verify

这听起来像新概念，但软件工程里早就有类似结构：CI 环境、构建环境、开发者工作区。差别在于，过去操作这些环境的是开发者，现在 Agent 也开始进入同一套环境。

Loop Engineering：把失败变成下一轮输入

Loop Engineering 解决的是更靠后的问题：Agent 一次写不对怎么办？

最直接的做法是让它跑起来。生成代码，执行验证，失败后读取错误，再生成下一版。直到测试通过，或者达到停止条件。

while True:
    code = generate()
    result = verify(code)

    if result.success:
        break

    feedback = collect_error(result)
    revise(code, feedback)

图：失败进入反馈回路，验证通过才走向成功出口

这套模式在 AI 圈里有很多名字：Self-healing、Auto Fix、Repair Loop、Reflection Loop。名字可以换，工程骨架没变：验证结果必须回流到下一轮生成，失败不能只躺在日志里。

Loop 的关键不是“让模型反思”这种抽象说法，而是把反馈做成可执行信号。单元测试、类型检查、Lint、构建日志、运行时错误，都是比自然语言评价更可靠的反馈源。能被机器稳定复现的失败，才适合进入闭环。

CI/CD 视角：新词背后是一条熟悉流水线

把 Loop Engineering 摊开看，它和 CI/CD 管道非常接近：

抓取 Issue、Bug 或任务描述
让 Agent 在隔离环境里修改代码
自动运行单元测试、Lint 和构建检查
失败时提取错误堆栈和日志
把反馈交回 Agent，进入下一轮修改
全部通过后提交变更或创建 PR

和传统 DevOps 对照，差异主要在“修复动作”这一环：

流水线环节	传统 DevOps	Agent Loop
触发方式	Push、Webhook、定时任务	Issue、任务队列、Cron、用户请求
隔离环境	Docker、CI Runner、临时工作区	Worktree、Sandbox、Runtime
执行逻辑	固定脚本	Agent 读取上下文后动态行动
验证机制	ESLint、Jest、构建脚本、单测	仍然依赖 ESLint、Jest、构建脚本、单测
失败处理	通知开发者修改	提取错误反馈给 Agent 再改
成功出口	打包、部署、通知、合并	提交 PR、生成补丁、通知或交付

有个细节很说明问题：验证环节至今仍主要交给确定性工具，而不是让大模型“看一眼觉得没问题”。工程系统对可复现校验的依赖没有被模型替代。概率模型负责提出修改，确定性工具负责裁判。

老方法的新位置：DevOps 不是背景板

很多 AI 工程新词，都能在旧的软件工程方法里找到对应物：

AI 语境里的说法	更底层的工程概念	常见实践
Prompt Engineering	输入协议设计	API Contract、接口说明
Context Engineering	知识管理与检索	Wiki、README、RAG、Confluence
Harness Engineering	执行环境封装	IDE、CI Runner、Docker
Loop Engineering	反馈闭环	CI/CD、TDD、自动化测试
Multi-Agent	分工协作	微服务、团队边界、责任拆分
Memory	状态管理	数据库、缓存、Session
Planner	工作流编排	Airflow、DAG、Workflow Engine

所以，Agent 工程化并不只是“模型越来越强”。更准确的说法是：模型被逐步接入了成熟的软件工程系统。输入协议、上下文管理、运行环境、验证机制、状态存储和工作流编排，这些老能力正在围着 Agent 重新组合。

能落地的 AI Coding 系统，最后往往不像一个聊天框，而像一套带队列、沙箱、日志、测试、回滚和权限边界的研发平台。

工程判断：别追黑话，先把闭环做硬

“这是新范式，还是 DevOps 的重新发明？”这个问题不用二选一。

形式确实变了。LLM 让系统多了一个能读需求、改代码、解释错误的执行者，这在过去很难成立。但底层方法没有突然换掉：任务要隔离，修改要验证，失败要反馈，状态要持久化，流程要看得见。

更值得投入的不是记住每个新名词，而是把闭环做硬：

需要做硬的环节	判断标准
上下文选择	Agent 拿到的信息是否足够、相关、不过量
执行隔离	修改是否可回滚，依赖是否可复现
验证信号	失败是否能稳定复现，并形成清晰反馈
循环边界	何时继续，何时停止，何时交给人
状态记录	每轮改了什么、为什么改、验证结果是什么

Agent 的价值，不是把 DevOps 抛到一边，而是让 DevOps 那套机制多了一个可调度的智能执行者。把 CI/CD、容器化、反馈控制和工作流编排这些地基打牢，再看 Prompt、Context、Harness、Loop，就不会被新词带着跑。

工程智慧没有消失。它只是换了一个入口，重新长在 Agent 系统里。

AI小老六