【学习笔记】从 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 的核心不是 RAG，RAG 只是其中一块。

更完整的上下文工程要处理四个动作：

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 框架会解决工程问题。

这同样不够。

框架能提供组件。

但你的业务边界、权限策略、验证标准、失败兜底，框架不会自动知道。

可以用一张表区分：

这四层不是互斥关系，它们是递进关系。

六、一个生产级 AI 系统的公式

如果把整套东西合在一起，我会用这个公式：

Production AI System = Model + Prompt + Context + Tools + State + Verification + Loop + Human Oversight

Model 是能力底座。

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 到 Loop，AI 工程化的四次跃迁