过去几十年里，“软件工程”解决的问题很明确：把需求写清楚、把逻辑写正确、把系统做稳定，然后按计划迭代、上线、维护。

但当我们开始构建“智能体（Agent）”——能理解目标、会规划步骤、能调用工具、能在环境中执行并自我纠错的系统——你会发现：很多传统软件工程 （Software Engineering）的方法仍然重要，却不再足够。我们正在从“写程序”升级到“训练与约束一个会行动的系统”，这就是“智能体工程（Agent Engineering）”的核心。

下面从几个关键维度，系统梳理智能体开发与传统软件开发的区别，以及这背后的工程升级。

【先看PPT再看文章】

---

一、目标从“实现功能”变成“达成任务结果”

传统软件工程强调功能闭环：输入是什么、输出是什么、流程怎么走，尽量可预测、可验证。开发者写下确定性的规则，系统按照规则执行。

智能体工程强调任务达成：用户给的是目标而不是流程，例如“帮我规划一周的授课安排并自动发提醒”。智能体需要自己拆解任务、选择工具、生成计划、执行并根据反馈修正。

这带来第一个范式变化：

• 软件工程：正确实现（Correctness of implementation）

• 智能体工程：可靠达成（Reliability of outcomes）

因此，评估也随之改变：

• 传统软件常用单元测试验证“函数返回值”；

• 智能体更常验证“在一组真实任务上是否稳定成功”，而且允许路径不同但结果满足约束。

二、核心资产从“代码逻辑”变成“策略 + 记忆 + 工具使用能力”

传统软件的主要资产是代码：

• 业务逻辑、数据结构、接口契约、性能优化。

智能体系统的核心资产更像一套“可执行认知架构”，通常包含：

• 策略（Policy）：如何理解目标、如何规划、何时求助、何时停止。

• 工具（Tools）：搜索、数据库、日历、邮件、代码执行、工作流等。

• 记忆（Memory）：用户偏好、上下文状态、长期目标、历史行动轨迹。

• 约束与护栏（Guardrails）：合规、安全、风控、成本限制、拒答策略。

代码仍然存在，但它更像“骨架”，而智能体的能力来自“骨架 + 策略层 + 交互层”的组合。这也是为什么很多团队会发现：把一个模型接到 API 上并不等于“做出了智能体”。

三、确定性被“概率性与涌现”取代：工程重点从“写对”变成“可控”

传统软件的行为主要是确定性的：同样输入得到同样输出（除非显式引入随机）。

智能体的行为天然带有概率性：同一目标可能产生不同计划、不同措辞、不同工具调用顺序。甚至在复杂任务中会出现“涌现行为”——它做了你没明确写下但又似乎合理的步骤。

因此智能体工程更像“驯化系统”：

• 你不能只问“它能不能做”，还要问

• “它会不会乱做、做到哪一步会跑偏、跑偏后能不能拉回来？”

工程手段也对应升级为：

• 用结构化输出减少歧义（JSON schema / function calling）

• 用状态机/工作流限制自由度（在关键步骤强约束）

• 用审计与回放追踪每一次决策（可观测性）

• 用多轮自检与反思降低错误率（self-check / verifier）

• 用成本与风险预算控制外部调用（工具权限、额度、审批）

一句话总结就是：

• 传统软件追求“正确”，智能体工程追求“可控”。

四、架构从“模块化系统”升级为“感知—决策—行动闭环”

传统系统的经典分层是：

• 前端、后端、数据库、缓存、消息队列……核心是数据流与业务流。

智能体系统多了一条关键链路：

• 感知（理解输入）→ 决策（规划推理）→ 行动（调用工具执行）→ 反馈（观察结果）→ 修正（迭代）

这意味着智能体架构的“中心”不再是某个接口，而是一个循环闭环。

一个成熟的智能体系统通常包含：

• 任务分解器：把目标拆为可执行子任务

• 规划器：决定执行顺序、分支与回退策略

• 执行器：调用工具、处理异常、记录结果

• 评估器/守门员：检查输出是否符合约束（事实、格式、合规）

• 记忆系统：写入、检索、遗忘机制（避免“越记越乱”）

• 可观测系统：日志、轨迹、成本、失败原因分析

它更像“自动化团队”，而不是“单个函数”。

五、测试从“用例覆盖”升级为“场景评测 + 失败驱动迭代”

传统软件测试的核心是：

• 覆盖边界条件、回归测试、接口契约测试。很多时候你能写出明确的与预期一致的输出。

智能体很难给出唯一正确答案，尤其是开放式任务。于是测试体系升级为：

• 任务集评测：一组代表真实业务的任务，统计成功率、平均步骤数、成本。

• 规则评分：用规则/模型/人工对结果打分（准确性、完整性、合规性、风格）。

• 对抗测试：诱导、越狱、提示注入、工具滥用等安全测试。

• 失败归因：失败到底来自理解、规划、工具、知识、还是输出格式？

• 离线回放 + 在线监控：线上错误可复现、可定位、可修复。

智能体工程的迭代方式更像“训练循环”：

• 收集失败 → 归因 → 加护栏/改提示/改工具/改流程 → 再评测。

六、交付从“版本发布”升级为“持续校准与运营”

传统软件发布后，系统逻辑相对稳定，主要是修 bug、加功能。

智能体系统上线后仍然需要“运营式工程”：

• 模型更新、提示模板调整会改变行为；

• 外部工具/数据源变化会引入新失败；

• 用户策略、权限边界、业务合规要求会动态变化；

• 成本（token、调用次数）会直接影响可用性。

所以交付形态变成：持续校准（Calibration） + 持续监控（Monitoring） + 持续优化（Optimization）

它更像在维护一个“会思考的生产系统”，而不是一套固定逻辑。

七、组织能力的升级：从“工程师写代码”到“跨域协作驯化系统”

智能体工程通常要求更紧密的跨域协作：

• 产品：定义“任务成功”的标准与边界

• 工程：搭建工具、权限、工作流、可观测性

• 数据/运营：构建评测任务集、分析失败模式

• 安全/法务：制定风险规则与合规护栏

• 领域专家：提供高质量示例、验证策略是否靠谱

最终形成一种新的工程文化：

• 不再执着于“一个函数对不对”，而是持续追问“系统在真实世界是否可靠、可控、可解释、可迭代”。

八、系统架构升级：从“面向 API 调用”到“智能体互联（Agent-to-Agent）”

在传统软件工程里，系统的主干通常是服务之间的 API 调用链：

• 用户请求进来 → 网关 → 若干微服务/模块 → 数据层 → 返回结果。这里的核心是“接口契约”和“请求响应”。

当我们进入智能体工程，架构的重心会发生一个明显迁移：

• 系统不再只是服务调用服务，而是“智能体协同智能体”，并把工具与服务当作可行动的资源。

也就是说，你构建的不是一条 API 链，而是一个可协作的行动网络。

（1）传统“面向 API”的架构特点：接口中心、流程外置

API 架构的假设是：流程由人（产品/工程）先定义好，然后系统照着跑。

所以关键能力是：

• 接口稳定：输入输出清晰、版本可控

• 流程确定：调用顺序由业务逻辑写死

• 异常处理：按预案兜底（重试、降级、超时）

• 扩展方式：加新功能=加新服务/新接口

这种架构非常擅长“确定性业务”，但对“开放式任务”会遇到瓶颈：一旦任务路径不固定，你就需要写大量分支逻辑，复杂度迅速爆炸。

（2）智能体互联的架构特点：目标中心、流程内生

智能体互联（Agent Interconnection）意味着系统由多个“有职责的行动者”组成，它们之间不是简单的 RPC，而更像组织协作：

• 有的智能体负责需求澄清/对话

• 有的负责规划与分解

• 有的负责检索与事实核查

• 有的负责执行工具调用

• 有的负责安全审计与合规

• 有的负责总结与交付格式化

此时系统的“主干”变成：

• 任务 → 角色分工 → 协作沟通 → 计划与执行 → 评估与回滚 → 交付

架构关注点也从“接口返回什么”升级为：

• 谁负责决策？

• 谁有权限调用哪些工具？

• 如何传递状态与证据？

• 如何避免互相误导、循环对话、或者越权执行？

(3）从“函数调用”到“协议协作”：互联需要“Agent 协议层”

服务互调靠 API 契约；智能体互联则需要更强的“协作协议”，至少包含四类信息：

• 身份与鉴权（Identity/Authentication)：谁是谁能做什么？

• 意图与目标（Goal/Intent）：这次交互要达成什么？

• 上下文与状态（State/Context）：当前已知事实、已做动作、剩余约束

• 证据与引用（Evidence）：检索到的依据、工具返回的原始结果

• 行动请求与授权（Action + Permission）：要做什么动作、是否允许执行、额度是多少

没有协议层，智能体之间就会退化成“互相发自然语言消息”，结果是：信息丢失、责任不清、不可追踪、不可审计。

（4）互联架构的三层形态：编排、联邦、市场化

实际工程里，智能体互联大致会走向三种结构（从强控制到弱控制）：

• 编排式（Orchestrated）

一个“主智能体/调度器”统一分派子智能体任务，子智能体像专家模块。

优点：可控、易审计；缺点：主智能体复杂、单点策略风险。

• 联邦式（Federated）

多个智能体对等协作，通过共享状态与协议互通；必要时引入仲裁者。

优点：扩展性好、职责清晰；缺点：需要更成熟的状态同步与冲突处理。

• 市场化/路由式（Router/Marketplace）

通过路由器按任务类型选择最合适的智能体，甚至动态竞标/投票决定方案。

优点：最灵活，适合多能力混合；缺点：评估与治理成本更高。

多数团队会从 A 起步，成熟后逐步引入 B 的联邦能力，再在局部使用 C 做弹性扩展。

（5）互联带来的新工程问题：不是“连起来”就行，而是“治理”

智能体互联会带来传统 API 架构里不显著的新问题：

• 一致性问题：多个智能体对同一事实理解不一致怎么办？

• 责任边界：错误发生时，是规划错、执行错，还是审计放行错？

• 循环与发散：智能体互相询问、反复确认、陷入对话环

• 权限与安全：谁能发邮件？谁能删数据？谁只能建议不能执行？

• 成本控制：多智能体协作会增加 token 和工具调用，必须预算化

• 可观测性：需要“跨智能体的全链路轨迹”，否则无法复盘

所以互联架构的成熟标志，不是“有很多智能体”，而是具备一整套治理能力：

• 统一身份与权限系统（capability-based access）

• 行动审计与可回放轨迹（trace + replay）

• 共享状态与证据存储（state store + evidence store）

• 失败仲裁与回滚机制（fallback / escalation）

• 评测与路由策略（选择哪个智能体、何时切换）

（6）一个直观对比：同样“调用服务”，为何互联更强？

在 API 思路下：“我要一个接口把结果算出来。”

在互联思路下：“我要一个由多个角色协作的系统，能在不确定条件下稳定把事办成。”

比如“安排一周课程并通知学生”：

• API 架构：你要写好所有分支：课程冲突怎么处理？通知模板怎么选？学生名单从哪来？失败怎么重试？

• 智能体互联：对话智能体澄清约束 → 规划智能体出方案 → 执行智能体调日历/通讯录/邮件 → 审计智能体检查收件人/措辞合规 → 总结智能体生成可确认的最终结果

不是“更复杂”，而是把复杂度从硬编码流程迁移到了协作与治理，从而获得更强的适应性。系统的架构重心从“接口链路”变为“行动网络”

从面向 API 调用到智能体互联，本质是：

• 过去：系统像“机器”，按既定程序运转

• 现在：系统像“组织”，有角色、有分工、有流程、有监督、有复盘

而智能体工程的架构升级，就是在构建一个可治理的“组织型系统”。

九、结语：智能体工程不是“软件工程 + 大模型”，而是“面向行动系统的工程学”

从软件工程到智能体工程，本质上是从“构建确定性系统”走向“构建受约束的行动者”。

传统软件工程依旧是底座：架构、工程质量、可观测性、权限与安全……仍然决定系统能否上线与规模化。

但智能体带来了新的核心矛盾：能力越强，自由度越高，失控风险越大。因此工程升级的方向不是让它“更聪明”那么简单，而是让它“更可靠、更可控、更可评估、更能在真实环境中稳定达成任务”。

如果要用一句话概括这次范式迁移：

• 软件工程解决“把逻辑写进系统”，

• 智能体工程解决“让系统在不确定世界里，按你的边界去行动”。