【学习笔记】从 Prompt 到 Loop，AI 工程化的四次跃迁-1/16

很多团队第一次做 AI 应用问题都长得差不多。一开始大家盯着提示词。这个词是不是不够精确要不要加角色要不要给示例要不要让模型一步步思考这些都重要。但过一段时间真正麻烦的问题会换一批。为什么同一个 prompt换一批输入就开始漂 为什么模型明明会回答却总拿不到正确资料 为什么 demo 能跑接进业务系统就不稳定 为什么 Agent 跑了十分钟看起来很努力最后没有完成目标 为什么成本、权限、日志、回滚一上来系统复杂度立刻翻倍这时候你会发现提示词不是没用。只是它已经不是问题的全部。过去两年AI 应用工程的重心至少经历了四次迁移Prompt Engineering - Context Engineering - Harness Engineering - Loop Engineering这不是为了造新词。它对应的是 AI 系统从“单次调用”走向“长期执行”的真实复杂度。一、Prompt把一次任务说清楚Prompt Engineering 解决的是第一层问题怎样把一次模型调用说清楚一个好的 prompt 通常会包含这些东西1、角色 2、任务 3、背景 4、约束 5、示例 6、输出格式 7、判断标准 8、失败兜底比如你要让模型抽取发票信息。一个弱 prompt 是帮我提取这张发票里的信息。一个工程化一点的 prompt 会写成你是财务系统的信息抽取模块。 从输入文本中提取 invoice_no、amount、currency、vendor、date。 只输出 JSON。 如果字段不存在值为 null。 不要猜测。 金额必须保留两位小数。差别很明显。第一个 prompt 像聊天。第二个 prompt 像接口契约。OpenAI 和 Anthropic 的提示工程文档本质上都在强调这件事把模型需要遵守的任务、上下文、格式和成功标准显式化。这一步仍然重要。不要因为 Agent 火了就看不起 prompt。很多失败不是因为系统不够复杂而是因为最基本的任务定义不清楚。但 prompt 有边界。它适合1、输入明确 2、输出明确 3、任务短 4、依赖少 5、无需外部动作 6、失败代价低一旦任务变成多步prompt 就开始吃力。因为问题不再是“怎么说”。而是“每一步该看什么”。二、Context把信息放对Context Engineering 解决第二层问题怎样让模型在每一步看到正确的信息这句话听起来简单。但它是很多 AI 应用从玩具到生产的分水岭。早期做 AI 应用很多人会直接把资料塞进 prompt。几页文档。几十条聊天记录。一堆数据库字段。全部塞进去。上下文窗口越大这个冲动越强。但 Anthropic 在 context engineering 文章里说得很清楚上下文工程是提示工程的自然延伸。当系统变成 Agent 后你要管理的不只是开头那段指令而是整个任务过程中流入模型的 token。上下文不是仓库。上下文是工作台。工作台上应该放当前步骤需要的东西。不该把整个仓库倒在桌上。一个真实 Agent 的上下文通常包含1、系统规则 2、用户目标 3、当前计划 4、检索到的事实 5、工具调用结果 6、历史决策 7、未解决问题 8、验证反馈这些信息不是一次性全部放进去。而是随着任务推进动态变化。所以 Context Engineering 的核心不是 RAGRAG 只是其中一块。更完整的上下文工程要处理四个动作1、Write把状态写到外部介质 2、Select选择当前最相关的信息 3、Compress压缩历史和工具输出 4、Isolate隔离不同子任务的上下文比如一个代码审查 Agent。它不应该一上来读取整个仓库。它应该先看1、PR diff 2、变更文件列表 3、相关测试 4、失败的 CI 日志 5、必要时再展开相关模块这是一个看代码Diff - 看范围Files - 查验证Tests - 查报错Logs - 看全局Modules的典型过程。如果它每次都把整个项目塞进上下文结果通常不是更聪明。而是更贵、更慢、更容易被无关信息干扰。Context Engineering 的目标是让模型每一步看到足够多但不要多到失焦。三、Harness把模型包进可控系统Prompt 和 Context 解决的是“模型看什么、怎么回答”。Harness Engineering 解决第三层问题模型之外需要哪些系统让它可靠行动OpenAI 在 Harness Engineering 文章里讲 Codex 的经验。Martin Fowler 也专门写过 Harness Engineering。共同点很明确AI 工程的杠杆不只在模型本身还在模型外部的环境。也就是1、工具 2、状态 3、权限 4、测试 5、反馈 6、审计 7、观测 8、回滚 9、人类监督这些加起来就是 Harness一个简单公式可以这样写Harness Tooling State Feedback Constraints Observability如果说 prompt 是说明书context 是工作台那 harness 就是车间。车间里不只是工人。还有工具架、质检台、安全线、物料记录、主管签字和返工流程。同一个模型放进不同 harness能力会完全不同。一个没有 harness 的代码 Agent可能只会写文件。一个好的 harness 会给它1、项目结构说明 2、代码规范 3、测试命令 4、静态检查 5、可写目录 6、禁止命令 7、失败重试策略 8、PR 评论格式 9、审计日志这时候模型不只是“生成代码”。它是在一个受控环境里完成工程任务。这也是为什么“模型越强工程越不重要”是误判。模型越强越能做事。越能做事就越需要边界。四、Loop让目标持续推进前面三层加起来已经能构建不少生产 AI 应用。但2026 年开始一个新问题越来越明显如果任务不是一次完成而是要持续运行呢比如每天早上整理团队动态 持续盯着 PR修复 CI 问题 每小时扫描新 issue 并分类 长期检查文档和代码是否漂移 等待外部事件后继续执行这类任务不是一次 prompt也不是一次上下文装配甚至不是单次 harness 执行。它需要循环。Loop Engineering 在这个系列里定义为围绕目标、触发器、状态、验证器、恢复机制和人类监督设计可长期运行的 Agent 循环系统。最小的 Agent Loop 可以写成Goal - Plan - Act - Observe - Verify - Update State - Repeat or Stop这个循环的难点不在“Repeat”。写个 while 循环很容易。难的是Claude Code Routines、Agent SDK 的 loop、OpenAI Agents SDK 的 Runner、传统队列和 cron其实都在从不同角度回答同一个问题怎么让 AI 不只是回答而是围绕目标持续推进Loop Engineering 不是替代 Harness。它是 Harness 在长期自动化场景下的进一步具体化。没有 Harness 的 Loop很危险。因为它会把一个不受控动作重复很多次。五、四次跃迁解决的不是同一个问题很多讨论混乱是因为大家把这四层混在一起。比如有人说提示词工程过时了。这不准确更准确的说法是Prompt Engineering 仍然负责单次调用的清晰度。 但复杂系统还需要 Context、Harness 和 Loop。也有人说上下文窗口越来越大Context Engineering 就不重要了。也不准确。上下文窗口变大只是让你能放更多东西。它没有告诉你什么东西该放、什么时候放、放多久、怎么删除。还有人说Agent 框架会解决工程问题。这同样不够。框架能提供组件。但你的业务边界、权限策略、验证标准、失败兜底框架不会自动知道。可以用一张表区分层级核心问题典型产物主要失败模式Prompt这次调用怎么说清楚prompt template指令含糊、格式漂移Context这一步该看什么context pipeline信息过载、缺事实Harness行动如何受控tools / state / evals / permissions工具乱用、不可审计Loop目标如何持续推进agent loop / routine / worker目标漂移、成本失控这四层不是互斥关系它们是递进关系。六、一个生产级 AI 系统的公式如果把整套东西合在一起我会用这个公式Production AI System Model Prompt Context Tools State Verification Loop Human OversightModel 是能力底座。Prompt 定义任务。Context 提供当前信息。Tools 连接真实世界。State 记录任务进度。Verification 判断是否正确。Loop 推进目标。Human Oversight 管住风险。少任何一块都可能在 demo 阶段看不出来。但生产会让它暴露。七、什么时候停在 Prompt 就够了不是所有任务都要升级。很多任务停在 Prompt Engineering 就足够。比如改写一段文案 总结一封邮件 把文本转成 JSON 分类一条用户反馈 生成一个 SQL 草稿这些任务的共同特点是输入短 边界清楚 不需要查外部资料 不需要执行副作用 结果容易人工检查这时候上 Agent 框架反而可能是工程过度。判断是否升级可以看这几个信号需要动态查资料 - Context 需要调用工具 - Harness 需要写入或执行副作用 - Permissions Audit 需要多轮推进 - State 需要持续运行 - Loop 需要稳定上线 - Evaluation Observability不要为了“高级”而升级要因为问题变了而升级。八、这个系列接下来怎么走这套连载会按四个阶段展开。第一阶段Prompt Engineering。我们先把“提示词没死只是不再够用”讲清楚。第二阶段Context Engineering。重点是信息选择、压缩、缓存、记忆和上下文生命周期。第三阶段Harness Engineering。重点是工具、状态、验证、权限、沙箱、观测和人类监督。第四阶段Loop Engineering。重点是长期运行、触发器、恢复、目标漂移、多 Agent 和自治边界。读完整个系列你应该能获得一张工程地图不是问“该用哪个框架” 而是先判断当前问题卡在哪一层。这比框架选型更重要。因为 AI 工程化的核心能力正在从“会提示”迁移到“会设计执行系统”。提示词仍然是入口但入口不是房子。参考资料• Prompt engineering | OpenAI API• Prompt engineering overview | Anthropic• Effective context engineering for AI agents | Anthropic Engineering• Harness engineering: leveraging Codex in an agent-first world | OpenAI• Harness engineering for coding agent users | Martin Fowler• Building Effective AI Agents | Anthropic• Claude Agent SDK overview• Automate work with routines | Claude Code Docs参考文献第一篇从 Prompt 到 LoopAI 工程化的四次跃迁