从 Prompt 到 loop：AI 工程正在走向 Runtime
AI 工程的中心，正在从 prompt 技巧转向 runtime：loop、状态与持续执行。
过去一年，AI 工程最大的变化，不是 prompt 越写越长，也不是模型回答越来越聪明。
真正的变化是：AI 在系统里的位置变了。
过去，AI 更像一个被人调用的函数。
你输入 prompt，它返回 answer。
output = model(prompt)
人是主程序。 AI 是工具函数。
人决定问什么。 人判断对不对。 人决定下一步。 人负责停止。
但现在，Agent 正在改变这个结构。
AI 不再只是被动回答，它开始读取上下文、调用工具、观察结果、修正错误，并在一个目标下持续运行。
这意味着，AI 正在从一个被调用的函数，走向一个被运行的系统。
更准确地说，不是模型自己变成了 Runtime，而是模型正在被装进 Agent Runtime。
这里的 Runtime，不是指模型本身，而是围绕模型构建的一整套运行环境：上下文、工具、权限、状态、日志、评估、失败恢复和停止条件。
模型仍然是核心能力，但真正决定系统稳定性的，越来越不是模型本身，而是模型外面的控制层。
这也是为什么我们会看到一堆新的工程概念：
Prompt Engineering。 Context Engineering。 Agent Harness Engineering。 Loop Engineering。
它们不是散乱的新词。
它们是在回答同一个问题：
如何把一个概率模型，包装成一个可控的执行系统？
一、Prompt：解决输入问题
最早的 AI 应用，本质就是一次函数调用。
output = model(prompt)
这个阶段，AI 是能力接口。
它可以写文章、解释概念、生成代码、总结材料、翻译文本。
但它不会自己决定下一步，也不会自己检查结果，更不会自己持续推进任务。
所以这个阶段最重要的是 Prompt Engineering。
因为 prompt 就是函数参数。
参数越清楚，返回结果越接近预期。
这也是为什么早期大家关注：
怎么设定角色？ 怎么描述任务？ 怎么给示例？ 怎么限制格式？ 怎么让输出稳定？
这些问题当然重要。
但它们只解决了 AI 工程的第一层问题：输入问题。
Prompt 再好，也不能替代上下文、工具权限、执行验证和停止条件。
所以 Prompt 没有过时。
只是它从“全部能力”，变成了“底层能力”。
二、Context：解决信息问题
后来大家发现，prompt 写得再好，如果上下文是错的，结果还是错的。
让 AI 修代码，但不给它完整代码结构，它只能猜。 让 AI 分析业务，但不给它真实规则和数据，它只能编。 让 AI 写方案，但不给它约束条件，它只能输出一份看起来正确的废话。
所以 AI 应用从：
output = model(prompt)
变成了：
output = model(prompt, context)
AI 不再只是需要一句指令，它需要一个工作现场。
这个现场里可能包括：
代码库。 产品文档。 接口定义。 数据库结构。 错误日志。 用户反馈。 历史决策。 业务规则。 测试结果。
这就是 Context Engineering 的价值。
它关心的不是“怎么问”，而是：
应该给模型哪些信息？ 哪些信息不能给？ 信息太多时怎么压缩？ 文档怎么切片？ 检索结果怎么排序？ 上下文怎么去重？ 怎么避免旧信息污染新判断？ 怎么保证模型看到的是当前有效的信息？
AI 的很多错误，不是模型能力不够，而是它站在了错误的信息环境里。
一个人在错误的信息环境里，越努力，错得越远。
AI 也是一样。
所以 Context Engineering 的本质，是把 AI 从一个孤立的语言模型，拉进真实工作现场。
但这里也有一个误区：
很多人以为 Context Engineering 就是“多塞资料”。
不是。
上下文不是越多越好，而是越相关、越干净、越可追溯越好。
错误的上下文不是增强能力，而是放大幻觉。
三、Harness：解决执行边界问题
再往后，AI 不只是回答问题了。
它开始调用工具。
它可以读文件。 可以改代码。 可以跑测试。 可以查日志。 可以打开浏览器。 可以调用 API。 可以搜索文档。 可以生成 patch。
这时候问题的性质变了。
如果 AI 只是说错了，最多是答案不好。
但如果 AI 可以执行动作，它就可能改错文件、运行危险命令、调用错误接口、无限重试，甚至在没有验证的情况下自信交付。
所以需要 Harness。
Harness 可以理解成模型外面的执行外壳。
它把模型、工具、权限、上下文、日志、评估器、错误处理机制包在一起，让 AI 能够接触外部世界，但不是无限制地接触。
没有 Harness，模型只是会说。 有了 Harness，模型才开始能做。
但“能做”之后，工程问题会突然变复杂：
模型能用哪些工具？ 工具参数怎么校验？ 文件系统怎么隔离？ 命令执行怎么限制？ 权限怎么控制？ 每一步怎么记录？ 失败结果怎么回传？ 什么时候需要人工确认？ 哪些动作必须禁止？
这就是 Harness Engineering 的核心。
它不是让 AI 更自由，而是让 AI 在边界内行动。
如果说 Prompt 是调用参数，Context 是运行内存，那么 Harness 就是执行外壳。
它的价值是：
给一个不稳定的概率模型，加上一个相对可控的工程容器。
这里也有一个常见误区：
很多人以为工具越多，Agent 越强。
但在真实工程里，工具越多，权限越大，风险也越大。
没有权限控制、日志记录和失败处理的工具调用，不是智能增强，而是事故入口。
四、Loop：解决持续运行问题
到了 Agent 阶段，AI 应用的形态再次变化。
它不再只是：
answer = ai(prompt)
而是开始接近：
while not done: plan() act() observe() evaluate() repair()
这就是 Loop。
AI 可以根据目标制定计划。 可以调用工具执行动作。 可以观察工具返回结果。 可以根据错误继续修正。 可以在一个目标下持续工作。
这时 AI 不再只是一个函数，也不只是一个工具节点。
它开始进入主循环的一部分。
过去，人是 main loop，AI 是其中一个函数调用。
人负责决定下一步。 人负责检查结果。 人负责修正方向。 人负责判断什么时候停止。
现在，Agent 开始承担一部分 main loop。
它会读上下文、选工具、执行、观察、修复，再继续下一轮。
所以 Loop Engineering 的问题不再是：
这一步怎么提示 AI？
而是：
目标怎么进入？ 上下文怎么加载？ 状态怎么更新？ 下一步由谁决定？ 失败后重试几次？ 什么时候换策略？ 什么时候停止？ 什么时候回滚？ 什么时候必须交给人？ 如何避免无限循环？ 如何避免成本爆炸？
Loop Engineering 不是 Prompt Engineering 的升级版。
它是另一个抽象层。
Prompt 解决一次调用。 Loop 解决持续运行。
如果用程序类比，Loop 就像 AI Agent 的 main.py。
它决定程序如何启动，如何加载上下文，如何调用工具，如何处理异常，如何判断完成，如何退出。
没有 loop，AI 只是一个工具函数。 没有控制，AI 就是一个不稳定的自动化系统。 没有退出条件，AI 就可能变成事故。
五、真正的主线：控制层越来越完整
所以这些概念放在一起看，讲的不是“prompt 怎么越写越长”。
它们讲的是：AI 系统里的控制层正在变得越来越完整。
层级解决的问题程序类比主要风险Prompt怎么问函数参数输入不清Context给什么运行内存上下文污染Harness怎么执行执行外壳越权行动Loop怎么持续运行main.py失控循环
对应到 AI 在系统里的位置：
第一阶段，AI 是函数。 第二阶段，AI 是带资料的函数。 第三阶段，AI 是可执行组件。 第四阶段，AI 被装进 Agent Runtime，开始参与运行循环。
对应到人的位置：
最早，人是操作者。 后来，人是反馈者。 再后来，人是流程设计者。 现在，人正在变成 runtime designer。
这不意味着人不重要了。
恰恰相反，人更重要了。
只是人的价值从“亲自操作每一步”，变成了“设计 AI 如何安全地操作每一步”。
过去人要会问问题。
现在人还要会定义上下文、权限、工具、评估、日志、失败恢复和停止条件。
这才是 AI 工程真正变难的地方。
六、这不是说 Prompt 不重要了
这里很容易出现一个误解：
既然 AI 工程正在走向 Runtime，那 Prompt Engineering 是不是不重要了？
不是。
Prompt 仍然重要。
只是它不再是全部。
就像写一个程序，函数参数当然重要。
但一个可靠系统还需要内存管理、权限控制、日志记录、异常处理、测试验证和退出条件。
Prompt 是入口，不是系统。
如果只会写 prompt，你能让 AI 回答得更好。
但如果你要让 AI 进入生产环境，你还必须关心：
它基于什么信息回答？ 它可以调用哪些工具？ 它执行动作是否越权？ 它失败后怎么处理？ 它什么时候必须停止？ 它的每一步是否可追溯？ 它的结果是否经过验证？
这就是从 Prompt 到 Runtime 的差别。
七、AI 不是普通自动化，而是概率自动化
传统自动化系统的问题通常是：
流程有没有写对？ 规则有没有覆盖？ 异常有没有处理？
但 Agent 系统更麻烦。
因为它不是纯确定性自动化。
它的核心决策来自概率模型。
这意味着它可能会合理地犯错。 可能会自信地犯错。 可能会在局部看起来正确，但整体方向错误。 可能会在错误假设上持续行动。 可能会把失败解释成“还需要再试一次”。
所以 Agent 时代最危险的事情，不是 AI 不会做。
而是 AI 会在错误方向上一直做。
这也是为什么 Loop 必须有控制层。
要有评估。 要有日志。 要有权限。 要有成本限制。 要有人工介入。 要有回滚。 要有退出条件。
让 AI 动起来不难。
难的是让 AI 可控地动起来。
一个没有控制层的 Agent，不是智能自动化，而是事故自动化。
八、工程师的位置正在重新定义
如果这条判断成立，那么工程师未来的能力栈也会变化。
过去工程师主要写业务逻辑。
现在工程师还要写 AI 的运行逻辑。
第一层，是输入设计能力。
你要能把目标、约束、输入、输出格式说清楚。
第二层，是上下文组织能力。
你要知道该给模型什么材料，也知道什么材料不能给。 你要能管理文档、代码、日志、数据库结构、历史决策和业务规则。
第三层，是执行边界设计能力。
你要能设计工具权限、参数校验、日志记录、失败处理和人工确认机制。
第四层，是循环控制能力。
你要能定义任务如何继续，如何验证，如何重试，如何停止，如何回滚，如何交给人。
这四种能力加起来，才是真正的 AI 工程能力。
不是让 AI 回答一次。
而是让 AI 在真实系统里持续、可控、可验证地行动。
九、结语：未来要写的不只是代码，而是 AI 的 main.py
如果把这条演化链压缩成一句话：
Prompt 是调用参数。 Context 是运行内存。 Harness 是执行外壳。 Loop 是 AI 的 main.py。
过去我们把 AI 当工具函数用：
output = model(prompt)
现在 Agent 正在变成一个运行系统：
while not done: plan() act() observe() evaluate() repair()
所以未来真正重要的能力，不只是会不会写 prompt。
而是会不会把一个概率模型，包装成一个可控的执行系统。
AI 工程真正的方向，不是让 prompt 变长，而是让 runtime 变稳。
不是把人从系统里拿掉，而是把人从 loop 里面，移动到 loop 上面。
未来工程师要写的不只是代码。
还要写 AI 的运行边界、验证机制和退出条件。
也就是，写 AI 的 main.py。