这个系列从一个很朴素的问题开始：

AI 工程化到底在工程化什么？

        最早，大家以为答案是 prompt。

        把提示词写好：给角色、给示例、给格式、让模型一步步思考。

这有用。但很快不够。

        因为真实任务不是一次回答：它需要资料、需要工具、需要权限、需要状态。

需要验证、需要恢复、需要人类监督、需要持续运行。

        所以 AI 工程化的重心一路迁移：

Prompt Engineering
  -> Context Engineering
  -> Harness Engineering
  -> Loop Engineering

        这不是四个时髦词，它是一条从“模型会回答”到“系统能执行”的工程路径。

一、Prompt：把任务说清楚

Prompt Engineering 没死，它只是位置变了。它不再是全部。它是入口契约。

一个好 prompt 至少要说明：

任务是什么
输入是什么
输出是什么
约束是什么
成功标准是什么
失败时怎么处理

        Prompt 层解决的是一次模型调用的稳定性。

        它适合边界清楚的任务：

抽取
分类
改写
生成草稿
格式转换
短流程判断

        但当失败来自外部信息、工具能力、权限、验证或长期状态时，继续改 prompt 没用。

        这时问题已经进入下一层。

二、Context：把信息放对

        Context Engineering 解决的是：

模型每一步应该看什么？

        不是把资料塞满，而是选择、压缩、隔离、更新。这个阶段的核心不是长上下文。

而是正确上下文。

        你要区分：

任务上下文
项目上下文
用户上下文
工具输出
检索结果
长期记忆
临时状态

RAG 是其中一部分，MCP 是连接外部数据和工具的协议层，Prompt caching 是成本优化手段。

Compaction 是长任务状态维护手段，这些都不是孤立能力。它们都是上下文生命周期的一部分。

三、Harness：把行动管住

        当模型开始调用工具，系统就进入 Harness Engineering。

        Harness 是模型之外的一切：

工具
权限
状态
测试
护栏
审计
观测
回滚
人类监督

        它决定 Agent 能不能进入真实工作流。没有 Harness，Agent 只能建议。

有了工具但没有 Harness，Agent 会危险。

        生产级 AI 系统必须回答：

Agent 能做什么？
不能做什么？
做错了怎么发现？
谁批准高风险动作？
如何复盘？
如何回滚？

        这也是 OpenAI、Anthropic、Martin Fowler 都在不同语境下强调的事：

        模型能力要变成生产能力，中间必须有运行环境和反馈结构。

四、Loop：把目标跑完

        Loop Engineering 解决的是：

Agent 如何围绕目标持续运行？

        这里再次强调：

        Loop Engineering 不是一个已经完全标准化的官方学科名。

        本系列把它定义为一组正在成熟的工程实践：

agent loop
routines
scheduled tasks
event-driven automation
long-running agents
verification loops
recovery loops

        Loop 的关键不是 while 循环。

        而是：

目标
触发器
状态
动作
验证
恢复
预算
人类升级

        一个 Agent 能执行一次任务，不代表它能长期运行。

        长期运行会带来：

上下文漂移
目标漂移
成本漂移
状态断裂
验证失效
责任模糊

        所以 Loop 必须建立在 Prompt、Context、Harness 之上。

        Loop 不是替代前面三层。

        Loop 是把前面三层串起来。

五、为什么终局不是聊天框

聊天框是入口。但它不是终局。

聊天框适合：

临时问题
探索想法
人工主导任务
一次性生成
低风险协作

企业里的高价值 AI 应用，最终会更像执行循环。

它们可能没有明显的聊天界面。

它们更像：

自动检查 PR 的质量回路
每天生成经营摘要的 routine
持续维护知识库的新鲜度检查
发现 CI 失败后自动定位和生成修复草稿
客户工单进入后自动分类、补资料、升级人工
合规变更后自动扫描受影响文档和流程

这些系统的核心不是“能聊天”。

而是：

能触发
能取数
能行动
能验证
能汇报
能恢复
能被审计

这就是 AI Operating Loop。

它不是一个具体产品名，而是一种系统形态。

Goal -> Trigger -> Context -> Action -> Verification -> State Update -> Recovery -> Human Oversight

六、AI Engineer 的新能力栈

        如果这个判断成立，AI Engineer 的能力栈也会变化。

        不是只会写 prompt，也不是只会调 API。而是要能设计智能执行系统。

至少包括八类能力。

6.1 Prompt Design

        能把任务、约束、格式和成功标准写清楚。

        能管理 prompt 模板、版本和评测集。

6.2 Context Architecture

        能设计上下文来源、检索、压缩、缓存、隔离和遗忘。

        知道什么时候该 RAG，什么时候该工具查询，什么时候该落盘。

6.3 Tool / API Design

        能给 Agent 设计好工具，工具名清楚，参数少而强，输出可验证，错误可恢复。

权限可控。

6.4 Eval Engineering

        能建立确定性测试和推理型评估。

        知道什么可以用单元测试，什么需要 reviewer，什么必须人工审核。

6.5 Workflow Orchestration

        能判断 workflow、single agent、multi-agent、routine 的边界。

        不把所有问题都扔给自治 Agent。

6.6 Security and Governance

        能设计权限、沙箱、审批、审计和回滚。

        知道哪些动作可以自动执行，哪些动作必须人类确认。

6.7 Observability

        能追踪 prompt、context、tool call、state update、verification result、cost、latency 和 human approval。

        看得见循环，才能调试循环。

6.8 Loop Design

        能设计目标、触发器、状态、预算、恢复和人工升级。

        让 Agent 不只是完成一次，而是稳定地进入工作流。

七、生产级 AI 系统检查清单

        最后，用一张清单收束整个系列。

        上线一个 AI Agent 或 AI 自动化系统前，至少检查这些问题。

        7.1Prompt

1. 任务边界是否明确？
2. 输出格式是否可解析？
3. 示例是否覆盖关键边界？
4. 失败时是否允许模型请求更多信息？

        7.2Context

5. 上下文来源是否可追踪？
6. 是否区分长期记忆、临时状态和外部数据？
7. 是否有压缩、缓存和遗忘策略？
8. 工具输出是否会污染上下文窗口？

        7.3Harness

9. 工具权限是否最小化？
10. 高风险动作是否需要审批？
11. 是否有确定性验证？
12. 是否有推理型复核？
13. 是否能回滚？
14. 是否有审计日志？

        7.4Loop

15. 是否有明确目标和退出条件？
16. 是否有状态文件或 session state？
17. 是否有 evaluator / verifier？
18. 是否有预算上限？
19. 是否有重试和升级人工机制？
20. 是否能解释每一轮为什么继续或停止？

        如果这二十个问题大部分答不上来，系统还在 demo 阶段。

        可以试用，不要闭环接生产。

八、下一阶段会发生什么

        我倾向于看四个方向。

        第一，Agent OS。

        不是一个大模型包办一切。

        而是一套围绕权限、工具、状态、调度、记忆、观测和审计的运行层。

        第二，Routine Marketplace。

        越来越多任务会被封装成可复用 routine。

        不是“给你一个 prompt”。

        而是“给你一个能接入数据源、工具和触发器的自动化单元”。

        第三，Workflow-native SaaS。

        未来很多 SaaS 不会只提供按钮和 API。

        它们会直接提供 Agent 可调用的工具、事件、权限模型和审计接口。

        第四，AI SRE。

        当Agent 开始持续运行，就需要有人负责：

目标是否漂移
成本是否异常
验证是否失效
工具是否退化
权限是否越界
恢复是否成功

        这和传统 SRE 很像。

        只是对象从服务变成了智能执行循环。

九、最后

        回到开头的问题。

        AI工程化到底在工程化什么？不是 prompt、不是模型、不是框架。

而是一个可验证的智能执行系统。

这个系统的公式可以写成：

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

        模型仍然重要，但模型不是全部；提示词仍然重要，但提示词不是系统。

        真正的工程能力，是把模型放进合适的上下文、工具、权限、状态、验证和循环里。

        让它能做事、让它做对事、让它做错时能被发现、让它失控前能停下、让人类从“修每个输出”，迁移到“改进产生输出的系统”。

        这就是我理解的 AI Engineering Evolution。

---

参考资料：

•  OpenAI: A Practical Guide to Building Agents
•  OpenAI Agents SDK Documentation
•  Anthropic: Building Effective Agents
•  Anthropic: Effective Context Engineering for AI Agents
•  Anthropic: Effective Harnesses for Long-Running Agents
•  Martin Fowler: Harness Engineering for Coding Agent Users
•  Claude Code Docs: Routines

参考文献：

第十六篇：AI 工程化应用的终局，从 Copilot 到 AI Operating Loop