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记录任务状态和中间产物有了 HarnessAgent 的行为从聊天变成一个工程循环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 对照差异主要在“修复动作”这一环流水线环节传统 DevOpsAgent 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、ConfluenceHarness Engineering执行环境封装IDE、CI Runner、DockerLoop Engineering反馈闭环CI/CD、TDD、自动化测试Multi-Agent分工协作微服务、团队边界、责任拆分Memory状态管理数据库、缓存、SessionPlanner工作流编排Airflow、DAG、Workflow Engine所以Agent 工程化并不只是“模型越来越强”。更准确的说法是模型被逐步接入了成熟的软件工程系统。输入协议、上下文管理、运行环境、验证机制、状态存储和工作流编排这些老能力正在围着 Agent 重新组合。能落地的 AI Coding 系统最后往往不像一个聊天框而像一套带队列、沙箱、日志、测试、回滚和权限边界的研发平台。工程判断别追黑话先把闭环做硬“这是新范式还是 DevOps 的重新发明”这个问题不用二选一。形式确实变了。LLM 让系统多了一个能读需求、改代码、解释错误的执行者这在过去很难成立。但底层方法没有突然换掉任务要隔离修改要验证失败要反馈状态要持久化流程要看得见。更值得投入的不是记住每个新名词而是把闭环做硬需要做硬的环节判断标准上下文选择Agent 拿到的信息是否足够、相关、不过量执行隔离修改是否可回滚依赖是否可复现验证信号失败是否能稳定复现并形成清晰反馈循环边界何时继续何时停止何时交给人状态记录每轮改了什么、为什么改、验证结果是什么Agent 的价值不是把 DevOps 抛到一边而是让 DevOps 那套机制多了一个可调度的智能执行者。把CI/CD、容器化、反馈控制和工作流编排这些地基打牢再看 Prompt、Context、Harness、Loop就不会被新词带着跑。工程智慧没有消失。它只是换了一个入口重新长在 Agent 系统里。推荐阅读Agent Loop 架构拆解让 AI Agent 自己跑完验收闭环SkillOpt 架构拆解把 Skill 文本当参数用执行轨迹训练 AgentMulti-Agent 执行闭环AI Coding 真正进生产要靠模型分工和工程护栏Agent Skill 状态机工程Mode-Step 网格如何拆开工作流边界Agent Skill Eval从触发信号到 A/B 基准如何把 Skill 做成可回归工程单元