文 | 王吉伟
从控制模型到控制智能体：LLM 时代工程范式的三次演进
Agent 工程全景：Prompt / Harness / Loop 三级技术栈完整拆解
Loop Engineering 是什么？从 Prompt 到 Harness 的 AI 工程范式全解析
2023年，Prompt Engineer 是 AI 行业最热门的岗位，年薪百万不是新闻。
2026年，行业讨论的热点已经变成了 Agent、Agent Runtime、Agent OS、Loop Engineering、Agent Governance。如果你还在简历上写「精通Prompt Engineering」，猎头可能会礼貌地建议你更新一下技能树。
很多人开始产生疑问：Prompt Engineering是不是已经过时了？
答案是否定的。Prompt没有消失。只是AI工程的重心已经发生了根本性的迁移。
大模型与Agent发展至今，AI行业经历了一场深刻但容易被忽视的工程革命，见下图。
这篇文章，王吉伟频道将完整梳理这条进化脉络。
Prompt Engineering - AI工程时代的起点
Prompt Engineering为什么会诞生
故事要从 GPT-3 说起。
2020年，OpenAI 发布了 GPT-3，一个拥有 1750 亿参数的语言模型。与之前的模型不同，GPT-3 展现了一种被称为 In-Context Learning 的能力：不需要微调，只需要在输入中给出几个示例，模型就能理解任务并给出合理的输出。
这个发现是革命性的。
它意味着自然语言第一次可以作为一种「编程语言」来使用。过去，让计算机执行任务需要写代码。现在，你只需要用自然语言描述你想要什么。
代码变成了自然语言，程序变成了Prompt，程序员变成了Prompt Engineer。
Prompt Engineering 应运而生。它本质上是对这种新型「编程范式」的方法论总结：如何通过精心设计输入指令，从大语言模型中稳定地获取高质量输出。
Prompt Engineering的发展历程
Prompt Engineering 并非一成不变，它经历了多个技术阶段的迭代。
Few-shot 时代。很快，人们发现在 Prompt 中提供 2-3 个示例可以大幅提升输出质量和格式一致性。Few-shot Prompting 成为标配。输入示例就像是给AI看的「参考答案」。
Chain of Thought 时代。2022年，Google Research 发表了 Chain-of-Thought Prompting 论文。
核心发现是：在 Prompt 中加入「让我们一步一步思考」这样的引导语，可以让模型在推理任务上的准确率大幅提升。这揭示了 Prompt 不只是「告诉模型做什么」，更是「引导模型如何思考」。
ReAct 时代。2023年，ReAct（Reasoning + Acting）模式出现。Prompt 不再是静态的指令，而是让模型在「思考」和「行动」之间交替进行。这是 Prompt 从「单次问答」走向「多步执行」的关键转折。Agent 的概念开始萌芽。
Structured Prompt 时代。到了 2024-2025 年，Prompt 工程走向了结构化、模板化、可编程化。XML 标签、Markdown 格式、JSON Schema 约束成为常见手法。Prompt 本身变成了一种「配置语言」。
这五个阶段，并不是简单的线性替代关系。
Zero-shot 和 Few-shot 至今仍是日常使用最频繁的 Prompt 方式。Chain of Thought 在复杂推理任务中不可替代。ReAct 是 Agent 的基础交互模式。Structured Prompt 在企业级应用中保证了输出的可靠性。
每一种技术，都在特定的场景中找到了最佳适配位置。
这种「技术的分层沉淀」是 AI 工程的一个核心规律：新范式的出现不意味着旧范式的消亡，而是意味着整个技术栈的丰富和深化。
Prompt Engineering 的方法论不是被淘汰了，而是变成了更大体系中的一个基础模块。就像汇编语言没有被高级语言淘汰，而是成为了编译器后端的一个组件。
Prompt Engineering解决了什么问题
Prompt Engineering 本质上解决的是四个核心问题：
输出控制。让模型按照你的意图输出，而不是天马行空。这是 Prompt 最基本的功能。在没有 Prompt Engineering 之前，使用大模型就像抽奖，你永远不知道它会说什么。
推理引导。通过 Chain of Thought、ReAct 等技巧，引导模型进行更有条理的推理。这本质上是在「借用」模型的推理能力。你通过 Prompt 设计了一条推理路径，模型沿着这条路径走。
格式约束。通过结构化 Prompt 确保输出格式一致，方便下游系统解析。JSON、表格、代码块的格式控制是典型应用。这对于企业级集成至关重要。
角色定义。通过「你是一个XX专家」这样的角色设定，激活模型在特定领域的知识分布。角色设定改变了模型输出的风格、深度和专业性。
总结来说，Prompt Engineering 的本质是控制模型输出的工程。它优化的是表达，而不是信息；控制的是单次推理，而不是持续执行。
Prompt Engineering的能力边界
然而，Prompt Engineering 有一个根本性的天花板。
它可以控制一次推理，却无法控制持续执行。它有四大局限：
没有状态。每次对话都是独立的。Prompt 无法让模型记住上一次做了什么、结果是什么。每次对话都是从零开始的。
没有记忆。模型的知识截止于训练日期。Prompt 能引导模型如何思考，但不能给模型注入它不知道的事实。企业的内部数据、最新的行业动态，都在模型的知识盲区里。
没有工具能力。Prompt 只能让模型生成文本。它不能调用 API、不能读写文件、不能搜索网页。模型是一个「只说不做」的智者。
没有执行闭环。Prompt 是一次性的。它不能让模型「做完、检查、修正、再做」。当任务复杂到需要多步执行和迭代修正时，单次 Prompt 的能力就到达了极限。
这四大局限，恰恰是后续 Harness Engineering 和 Loop Engineering 要逐一解决的问题。
Harness Engineering - 被忽视的Agent革命
为什么Prompt开始不够用了
当 AI 从「回答问题」进化到「执行任务」，Prompt Engineering 的局限性就暴露无遗。
企业发现，真正的问题不是「AI怎么回答得更好」，而是「AI怎么把活干了」。
一个客服机器人光会回答还不够，它需要查询订单系统、修改配送地址、发起退款流程。一个代码助手光会写代码还不够，它需要理解项目结构、运行测试、修复 Bug、提交 PR。
从 Answer 到 Action，是从「对话式 AI」到「代理式 AI」的质变。ChatGPT 是一个对话工具。Agent 是一个执行系统。前者在等你的下一个问题。后者在主动完成任务。
这个转变带来了全新的工程需求：调用工具、访问系统、长期记忆、权限控制、多轮执行。Prompt 解决不了这些问题。你需要一个更大的框架。
什么是Harness Engineering
Harness，直译是「马具」或「缰绳」。在软件工程中，Harness 指的是测试框架中用于驱动和验证被测代码的脚手架代码。在 Agent 领域，Harness 被赋予了更丰富的含义。
文章披露了一个惊人的数据：一个小团队在5个月内让 Codex Agent 自主生成了约100万行代码，人工没有写一行生产代码。
随后，Birgitta Bockeler 在 Martin Fowler 的博客上发表了更系统化的阐述，将 Harness Engineering 的落地内容归纳为上下文工程、架构约束（Architectural Constraints）、熵管理 / 垃圾回收（Entropy Management）三大方向，覆盖智能体全生命周期管控。
论文《Agent Harness Engineering: A Survey》定义了Harness Engineering的七层架构（缩写为ETCLOVG）约束：
1.Execution environment（执行环境层）：沙箱、运行时、权限隔离；
2.Tool interface（工具接口层）：工具协议、调用封装、权限管控；
3.Context management（上下文管理层）：记忆系统、信息检索、提示词体系；
4.Lifecycle/Orchestration（生命周期与编排层）：任务调度、状态流转、子代理管理；
5.Observability（可观测层）：日志、追踪、监控告警；
6.Verification（验证层）：校验规则、测试闭环、反馈机制；
7.Governance（治理层）：合规审计、权限治理、持续优化。
国内技术社区，也基于 Claude Code 等生产级 Agent 的实现，结合学术框架做了本土化归纳的七层架构：意图层、上下文层、工具层、约束层、验证层、记忆层、改进层。
这个面向工程落地的拆解，更加通俗易懂。
不难看出，Harness Engineering 的核心定义是：构建 Agent 运行时系统的工程体系。在国内，它被优雅的翻译为「驾驭工程」。
换言之，Prompt Engineering 关心的是「给模型什么指令」。Harness Engineering 关心的是「给模型什么环境」。
这个环境包括它能看到什么信息、能调用什么工具、有什么行为约束、如何验证输出。
用一个简单的等式来概括：
Agent = LLM + Harness
在Harness Engineering中，治理层非常重要，关系着Agent企业级应用的安全与稳定运行。在基于Agent的人机协同中，更多体现的是人与Agent（human in the loop）的协作关系。
对HITL感兴趣的读者，可以看看下面这篇文章：
从 Human-in-the-Loop 到 Agent Governance，理解 Agent 时代的人类角色
工程角度看Harness Engineering核心组成
从工程角度来看，Harness Engineering 其实是一个复合工程领域，它由五个关键子系统构成。
Context Engineering：让 Agent 看到什么。大模型的上下文窗口是 Agent 的「视野」。Context Engineering 负责管理和优化输入给模型的信息：哪些文档应该放进上下文、如何组织信息结构、如何处理上下文长度限制。
2025年，Andrej Karpathy 提出「Context Engineering 正在取代 Prompt Engineering」，指的就是这一层的兴起。
RAG Engineering：让 Agent 知道什么。检索增强生成（RAG）让 Agent 能够从外部知识库中检索相关信息。
这解决了「模型训练数据过时」的问题。向量数据库、嵌入模型、检索策略、重排序构成了 RAG Engineering 的技术栈。
Memory Engineering：让 Agent 记住什么。人类的智能依赖于记忆，Agent 也是如此。短期记忆让 Agent 在单次会话中保持上下文连贯。长期记忆让 Agent 跨会话积累经验。
Memory Engineering 涉及对话历史的存储和检索、关键信息的持久化、记忆的压缩和淘汰策略。
Tool Engineering：让 Agent 能够做什么。没有工具，Agent 只是一个会说话的模型。有了工具，Agent 可以搜索网页、查询数据库、调用 API、操作文件系统。
Tool Engineering 负责工具的定义、注册、发现和调用机制。MCP（Model Context Protocol）的出现将工具接入标准化，是这一层的重要基础设施。
Policy Engineering：让 Agent 不能做什么。这是 Harness 中最容易被忽视但最为关键的一层。Agent 的行为必须在安全边界内。
Policy Engineering 定义权限模型、设置护栏规则、控制 Token 消耗上限、过滤敏感输出。在企业级场景中，Policy Engineering 的缺失等同于合规灾难。
它们共同构成了一个复杂但自洽的 Agent 运行环境。
从工程哲学的角度看，Harness Engineering 引入了一个关键的思维方式转变：你不再问「模型能做什么」，而是问「我需要给模型一个什么样的环境，它才能可靠地完成这个任务」。
环境的设计能力，替代了 Prompt 的编写能力，成为工程师的核心竞争力。
Agent OS的雏形
当 Context、RAG、Memory、Tool、Policy 这五个子系统整合到一起，就形成了一个 Agent 运行时环境。这本质上是一个「Agent 操作系统」的雏形。
从架构视角看，Agent OS 包含以下核心组件：
Agent Runtime：管理 Agent 的生命周期，包括启动、执行、暂停、终止。
Agent Memory：管理短期和长期记忆，支持跨会话状态持久化。
Agent Tool Bus：提供工具注册和调用的统一接口，类似操作系统中的系统调用层。
Agent State Manager：追踪 Agent 执行过程中的状态变化，支持断点续传和错误恢复。
Google Cloud AI 总监Addy Osmani 认为，Harness 是基础，Loop 建立在 Harness 之上。
因此从Prompt发展进程角度，我们可以将其概括为一个三层架构：Prompt Engineering 是第一层，Agent Harness Engineering 是第二层，Loop Engineering 是第三层。
总结来说，Harness Engineering 的本质是控制 Agent 运行环境的工程。它让你的 Agent 从「能说」变成「能做」，从「单次问答」变成「系统化执行」。
但它还有一个局限：你仍然在操作 Agent。每次任务完成，你需要审查结果，然后启动下一个任务。你仍然是 Agent 的「司机」。
而 Loop Engineering 要做的，是把方向盘交出去。
Loop Engineering - Agent时代的新控制层
为什么Workflow开始失效
在 Loop Engineering 出现之前，企业自动化走的是 Workflow 路线。
传统 Workflow 的逻辑很清晰：定义流程，然后按流程执行。审批流、ETL 管道、CI/CD 流水线都是这个思路。
但在 Agent 时代，Workflow 遭遇了三个致命问题。
流程刚性。Workflow 假设你可以预先定义所有可能的路径。但在 Agent 执行任务的过程中，中间状态是高度动态的。Agent 发现了一个 Bug，它需要决定是继续当前任务还是先修 Bug。
Workflow 无法优雅地处理这种情境切换。
长尾场景爆炸。真实世界的任务有无数种变异。一个「写市场调研报告」的任务，Workflow 可能需要定义几十种分支路径：数据源 A 不可用时怎么办、搜索结果不够时怎么办、格式不一致时怎么办。
维护这种 Workflow 的成本，随复杂度指数级增长。
维护成本高。Workflow 的每一步都需要人工定义和维护。
当业务逻辑变化时，你需要修改 Workflow 的定义。当 Agent 工具升级时，你需要更新 Workflow 中的工具调用逻辑。当模型能力提升时，你之前精心设计的步骤可能已经过时。
什么是Loop Engineering
Loop Engineering 提供了一种完全不同的范式：从流程驱动到目标驱动。
你不再定义「第一步做什么，第二步做什么」。你定义一个目标和一套约束，然后让 Agent 在一个循环中自主地「观察、思考、行动、评估、重新规划、重复」，直到目标达成。
Loop 的标准结构可以概括为：
Goal（目标定义）
|
Observe（观察当前状态）
|
Think（分析局面，制定计划）
|
Act（执行行动）
|
Evaluate（评估结果）
|
Replan（根据反馈调整计划）
|
Repeat（循环直到目标达成或超时）
Peter Steinberger，开源 Agent 项目 OpenClaw 的创建者，发了一条 220 万浏览量的推文：「你不应该再手动提示 AI 编程助手了。你应该设计循环系统，让 Agent 自己提示自己」。
Boris Cherny，Anthropic Claude Code 的负责人，在公开演讲中说：「我不再直接提示 Claude 了。我有一套 Loop 在运行，它们负责提示 Claude 并决定下一步做什么。我的工作是写 Loop」。
Addy Osmani系统性地将这一实践命名为 Loop Engineering，并定义了五大组件：Automations、Worktrees、Skills、Plugins/Connectors、Sub-agents。当然，还有记忆也非常重要。
下图，是Addy Osmani整理的Codex与Claud Code对于这写组件的应用。
Primitive | 循环内职责 | Codex 应用 | Claude Code |
自动化 | 定时执行任务发现与分拣 | 自动化面板：可选择项目、提示词、执行频次、运行环境；结果汇入分拣收件箱；支持「运行至完成/目标达成」模式 | 定时任务与 Cron 调度、钩子、GitHub Actions、循环执行/目标导向模式 |
工作树 | 隔离并行开发的功能特性 | 每个执行线程内置独立工作树 | 子智能体基于 Git 工作树实现——工作树隔离：独立工作目录 |
技能 | 将项目知识编码化沉淀 | 智能体技能（SKILL.md），支持通过名称显式调用或隐式触发 | 智能体技能（SKILL.md） |
插件 / 连接器 | 对接外部工具 | 连接器（MCP 协议）+ 面向分发的插件体系 | MCP 服务端 + 插件体系 |
子智能体 | 方案构思与结果验证 | 子智能体以 TOML 配置格式定义在.codex/agents/目录下 | 任务型子智能体定义在 .claude/agents/ 目录，支持智能体团队协作 |
状态管理 | 追踪任务完成进度 | 通过连接器对接 Markdown 文档或 Linear 项目管理工具 | 通过 MCP 对接 Markdown（AGENTS.md、进度文件）或 Linear 工具 |
3个人都提到了Loop Engineering，这不是巧合，这是范式转移的明确信号。
七种典型Loop模式
Loop Engineering 不是一种单一的架构，而是包含了多种设计模式。
ReAct Loop：边思考边行动。这是最基础的 Loop 模式。Agent 在每一轮中先「推理」当前应该做什么，然后「行动」，观察结果，进入下一轮推理。ReAct 模式适用于任务路径不明确、需要逐步探索的场景。
Plan-and-Execute：先规划再执行。LangChain 的 Sydney Runkle 详细描述了这种模式：Agent 首先生成完整的执行计划，然后逐步执行，每步完成后对比计划和实际结果。当任务结构清晰、可以提前规划时，Plan-and-Execute 比 ReAct 更高效。
Reflection Loop：自我反思与纠错。Agent 完成一步后，用一个独立的「评判者」模型或规则来评估输出质量。如果不合格，将反馈注入上下文，让 Agent 重新执行。这种模式在代码生成、文档写作等需要高质量输出的场景中特别有效。
Tree of Thought：多路径探索。面对复杂问题时，Agent 同时探索多条可能的推理路径，比较结果，选择最优方案。这种模式适用于需要创造性解决方案的场景。
Graph Loop：状态机与图结构控制。使用有向图来定义 Agent 的状态转换逻辑。LangGraph 是这种模式的代表实现。Graph Loop 比纯粹的 ReAct 更可控，因为状态转换路径是显式定义的。
Multi-Agent Loop：多智能体协作。主 Orchestrator 将复杂任务分解，分发给多个 Specialist Agent，收集结果后进行整合。Firecrawl 的 Hiba Fathima 指出，Multi-Agent Loop 的核心挑战是协调：各个 Sub-agent 之间的信息传递、冲突解决和结果合并。
Self-Improving Loop：持续学习与优化。这是最高级的 Loop 模式。Agent 不仅执行任务，还从每次执行中学习，优化自己的策略。LangChain 将其称为「Hill-climbing Loop」：Agent 持续尝试改进，每次迭代都向更好的方向移动一步。
例如，一个代码审查 Agent 可能同时使用 ReAct Loop（理解代码逻辑）、Reflection Loop（自我纠错）和 Multi-Agent Loop（主 Agent 分配审查任务给子 Agent）。
swyx 在 Latent Space 中提出了一个更深刻的概念：「Loopcraft」-- 堆叠循环的艺术。
他认为，下一世纪的竞争核心就是「谁能更有效地堆叠循环」。当你需要更高的可靠性时，就往下一层走（增加验证循环）。当你需要更大的杠杆时，就往上一层走（增加自动化循环）。
这种「循环的可组合性」是 Loop Engineering 最强大的属性。就像函数式编程中的函数组合一样，Loop 可以被设计为独立的、可测试的、可组合的模块。
一个 Verification Loop 可以在任何需要质量保证的场景中复用。一个 Heartbeat Loop 可以监控任何需要持续关注的状态。
一个 Multi-Agent Loop 可以将任何复杂任务分解为可并行的子任务。
为什么Loop正在取代Workflow
Loop 和 Workflow 的根本区别在于控制逻辑的变化。
Workflow 控制步骤。你定义「A-B-C」的执行顺序。模型是执行者，不是决策者。每一步的走向由你预先确定。
Loop 控制目标。你定义「达成X」的目标和「不超过Y」的约束。模型既是执行者，也是决策者。每一步的走向由模型根据当前状态动态决定。
这是从「流程自动化」到「决策自动化」的质变。Workflow 是给工人一本操作手册。Loop 是给工人一个目标、一套工具、一套安全规范，然后说「你自己看着办」。
Lushbinary 提出了一个实用的成熟度阶梯：手动 -> 协助 -> 委托 -> 编排 -> 自主。不要一步跳到完全自主。先从让 Agent 协助你完成子任务开始，逐步增加 Agent 的自主权，每次都验证质量，然后再进入下一级。
当然，进入Agent时代，Workflow也进化成了Agentic workflow，也是为了适应这种自主性和主动性。
LangGraph与Loop时代
Loop Engineering 的崛起与 LangGraph 的流行是一体两面。
LangGraph 是一个基于有向图的 Agent 编排框架。它的核心抽象是：Agent 的执行过程是一个图，节点是状态，边是转换逻辑。
通过定义状态机和条件路由，LangGraph 在「完全自主的 ReAct Loop」和「完全确定的 Workflow」之间找到了一个完美的中间地带。
为什么 Graph 如此重要？因为它解决了 Loop 最大的痛点：可预测性。一个纯 ReAct Loop 的执行路径是完全动态的，你无法预知 Agent 会做什么。
而 Graph Loop 通过显式的状态转换定义，让你既能享受 Loop 的灵活性，又能保持 Workflow 的可控性。
LangGraph 的流行还揭示了一个更大的趋势：Agent Runtime 正在成为新的基础设施。从 LangChain 到 LangGraph 再到 LangSmith（Agent 可观测性平台），一个完整的 Agent 开发生命周期管理平台正在成型。
值得一提的是，Loop Engineering 的崛起背后有一个关键的技术前提：模型能力的时间维度突破。
Requesty 的数据显示，METR 基准测试中，Claude Opus 4.6 能完成 50% 需要 12 小时时长的任务。而一年前，Opus 4 只能坚持 1 小时 40 分钟。能力翻了 6 倍。
当模型能连续工作的时间超过了人类一天的注意力时长，Loop Engineering 就成了必然：在 12 小时的运行中，人类不可能每一轮都盯着。
总结来说，Loop Engineering 的本质是控制智能体行为的工程。它让 Agent 从「被操作的工具」变成「自主运行的员工」。
但 Loop 不会取代 Harness。Loop 建立在 Harness 之上。Harness 负责「安全可靠」，Loop 负责「自主高效」。两者共同构成了 Agent Engineering 的核心。
企业Agent Engineering全景图
从Prompt到Loop发生了什么
第一阶段：控制模型。Prompt Engineering 解决的是「模型怎么输出」的问题。这是 AI 工程的起点。Prompt 是工程师与模型之间的第一层界面。
第二阶段：控制运行环境。Harness Engineering 解决的是「Agent 怎么运行」的问题。Context、RAG、Memory、Tool、Policy 五大子系统构建了 Agent 的操作系统层。
第三阶段：控制行为。Loop Engineering 解决的是「Agent 怎么持续做对的事」的问题。通过目标驱动、循环执行、动态决策，让 Agent 具备自主行为的能力。
每一次进化都不是对前一阶段的否定，而是将其作为基础，在此之上构建更高层次的控制能力。Prompt 嵌入到 Harness 中，Harness 嵌入到 Loop 中。每一层都依赖于下一层提供的稳定性。
Agent时代诞生的Engineering谱系
Agent 时代催生了一个全新的工程学科谱系。这不是一个替代关系，而是一个叠加关系。每一个新领域的出现，都是在已有基础上增加一层新的抽象：
工程领域 | 核心关注点 |
Prompt Engineering | 控制模型输出 |
Context Engineering | 控制信息输入 |
RAG Engineering | 知识检索与注入 |
Memory Engineering | 状态持久化 |
Tool Engineering | 能力扩展与集成 |
Harness Engineering | 运行环境治理 |
Loop Engineering | 行为控制 |
Multi-Agent Engineering | 协作编排 |
Evaluation Engineering | 质量评估 |
Governance Engineering | 安全与合规 |
企业级Agent Engineering参考架构
综合前面的分析，我们可以抽象出一个六层企业级 Agent Engineering 参考架构：
L6 Applications（应用层） |
L5 Loop Layer（行为层） |
L4 Harness Layer（运行层） |
L3 Knowledge Layer（知识层） |
L2 Model Layer（模型层） |
L1 Infrastructure（基础设施）
每一层都是独立的工程领域，有自己的方法论、工具链和最佳实践。
这个架构最关键的设计原则是分层解耦：Model 不等于 Agent，Agent 不等于 Workflow，Workflow 不等于 Tool System。
每一层应该可以独立升级、替换和优化。这正是云原生架构在 AI 领域的延伸。
如果用 AWS 来类比理解：
AWS 层 | Agentic AI 对应层 |
EC2 / S3 | Infrastructure（基础设施） |
Bedrock models | Model layer（模型层） |
OpenSearch / RAG | Knowledge layer（知识层） |
Lambda | Tool execution（工具执行） |
Step Functions | Loop orchestration（循环编排） |
IAM | Policy engine（策略引擎） |
CloudWatch | Observability（可观测性） |
Application layer | Agent apps（Agent应用） |
这个类比揭示了一个深刻的趋势：Agent OS 正在成为云原生架构的新抽象层。就像 Kubernetes 抽象了计算资源的管理，Agent OS 在抽象智能任务的管理。
Agent OS正在成为新的企业软件基础设施
过去二十年，企业软件基础设施经历了三次重大变迁。
从 ERP/CRM/BPM 代表的流程管理时代，到云计算代表的弹性基础设施时代，再到 AI Engineering 代表的智能增强时代。每一次变迁都重塑了企业软件的技术栈。
现在，第四次变迁正在发生：Agent OS 正在成为新的企业软件基础设施层。
Agent OS 不是传统操作系统的替代品。它是一个新的抽象层：在操作系统之上、在应用层之下，专门为 AI Agent 提供运行时支持的系统层。它包括 Agent 生命周期管理、工具注册与发现、状态管理、权限控制、可观测性。
本质上，它是在 LLM 之上构建的一个Agent 中间件。
这个趋势的终端形态是什么？是 Agentic ERP。是 Agentic CRM。是 Agentic Enterprise。
扩展阅读：Agentic ERP转型路线图：从ERP数字化到Agentic Enterprise的实施方法论
当企业的核心业务流程不再由人来操作软件系统，而是由 Agent 来自主运行时，Agent OS 就不再是一个可选的工具，而是一个必需的基础设施。
从：ERP、CRM、BPM 到 Agent OS，标志着企业正在从「构建软件系统」走向「构建自主运行的智能系统」。这个转变，或许才是 Agentic AI 革命真正开始的地方。
结语：从软件工程到智能体工程
过去二十年，工程世界的主线是清晰的：
Software Engineering → Cloud Engineering → AI Engineering
未来十年，主线将转向：
Agent Engineering → Agentic Engineering
Prompt 不会消失。它会继续进化，作为模型交互的基础手段。
Harness 不会停止演化。它会变得越来越复杂，越来越像一个真正的操作系统。
Loop 也不会是终点。它只是 Agent 自主性道路上的一个里程碑。
十年前，一个工程师一天能写几百行代码。
五年前，有了 Copilot，一个工程师一天能 Review 几千行 AI 生成的代码。
今天，有了 Loop，一个工程师可以在睡觉的时候让 Agent 持续工作。
每一次杠杆的放大，都意味着人类工程师的角色在发生根本性的变化：从操作者，到监督者，到治理者。
Addy Osmani 在文章结尾写了一句话，可以作为这个时代的注脚：Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
翻译过来就是：构建循环，但要像一个打算继续做工程师的人那样去构建它，而不只是一个按启动按钮的人。
在工业时代，工程师设计机器。在软件时代，工程师设计系统。在 Agent 时代，工程师设计循环。
这可能是我们这个时代最深刻的一场工程革命。而它才刚刚开始。
从 Prompt Engineering 到 Harness Engineering，再到 Loop Engineering，AI 工程的演进从来不是替代，而是层层叠加的抽象升级。
工程师的角色从写提示词，到搭建运行环境，再到设计自主循环，手中的杠杆每放大一次，对应的能力边界就拓展一次。
这场从软件工程到智能体工程的革命才刚刚开始，最先掌握新范式的人，将率先吃到 Agent 时代的技术红利。
