---
title: "你可能建错了智能体：建设系统智能体，而不是复制研发工序"
url: https://www.agilean.cn/insights-new/system-agents-not-pipeline-agents/
updated: 2026-10-17
description: "按需求、设计、编码、测试等研发工序建设 Agent，往往只是复制旧流水线，把人与人交接变成 Agent 与 Agent 交接。吴穹主张 AI Native 团队围绕产品、业务领域和软件系统建设长期负责的系统智能体（System Agent），让它拥有系统上下文、记忆、Skills、权限与质量基线，并区分逻辑 Agent 与任务实例。"
publisher: "Agilean（爱捷软件开发（深圳）有限公司）"
language: zh-CN
---

按需求、设计、编码、测试等研发工序建设 Agent，往往只是复制旧流水线，把人与人交接变成 Agent 与 Agent 交接。吴穹主张 AI Native 团队围绕产品、业务领域和软件系统建设长期负责的系统智能体（System Agent），让它拥有系统上下文、记忆、Skills、权限与质量基线，并区分逻辑 Agent 与任务实例。

# 你可能建错了智能体：建设系统智能体，而不是复制研发工序

作者：吴穹 发布于 2026/10/17

最近，不少团队开始规划自己的“智能体矩阵”：需求分析智能体负责理解需求，设计智能体负责输出方案，编码智能体负责生成代码，测试智能体负责生成用例和执行验证。如果把研发流程画成一条流水线，几乎每一个传统岗位旁边，都可以再放上一个 Agent。

这看起来很合理。既然过去由不同岗位完成这些工作，现在就给每个岗位配置一个智能体，甚至让智能体直接替代其中一部分工作。

但这里可能藏着一个根本问题：**我们正在用旧组织的地图，建设新世界的智能体。**

岗位换成了 Agent，流水线却没有消失；每个环节都变快了，系统交付却未必同步变快；人和 Agent 都在忙，需求仍然要在不同角色之间反复解释，背景知识仍然要反复装载，设计决策仍然可能在编码阶段丢失，测试发现的问题仍然要沿着原来的链条向上追溯。

如果是这样，我们建设的可能不是 AI Native 研发体系，只是一条由 Agent 加速的旧流水线。

![按研发工序建设Agent，复制了旧流水线](https://www.agilean.cn/images/insights/system-agents-not-pipeline-agents/wrong-agent-pipeline.jpg)

*按研发工序建设Agent，复制了旧流水线*

## 按工序建设Agent，本质上仍是局部优化

需求分析、设计、编码和测试，原本就是工业化软件生产形成的专业分工。这套分工解决了复杂系统时代的规模化协作问题，但也带来了明显代价：知识被岗位切割，责任被阶段切割，工作通过文档和工单层层交接。

如果按照同样的边界建设 Agent，结果往往是：需求 Agent 掌握用户描述，设计 Agent 掌握方案，编码 Agent 掌握代码，测试 Agent 掌握用例。它们各自拥有一小段上下文，却没有任何一个 Agent 真正理解并持续负责整个系统。

更麻烦的是，生成式 AI 对上下文的依赖远高于传统自动化工具。传统工具只需要明确输入和规则，Agent 则需要知道系统为什么存在、过去做过哪些决策、哪些约束不能打破、代码如何运行、质量标准是什么，以及一次修改会影响哪些上下游关系。

当这些信息被分散在多个按工序划分的 Agent 中，团队就不得不重新发明一套 Agent 之间的需求文档、设计文档、任务拆解和验收流程。人类组织里已经存在的上下文损耗，会再次发生在 Agent 之间。

**我们以为消灭了交接，实际上只是把“人与人交接”改成了“Agent 与 Agent 交接”。**

## 真正稳定的边界不是工序，而是系统

需求、设计、编码和测试都是工作方式，会随着模型能力快速变化；产品、业务领域和软件系统却是企业长期经营和演进的对象。

因此，企业更值得建设的，不是一批与传统岗位一一对应的 Agent，而是产品 Agent、业务领域 Agent，以及一个个系统 Agent。

所谓系统 Agent，是以一个可持续演进的业务或技术系统为责任边界，长期拥有这个系统的上下文、知识与记忆、Skills、工具、代码和文档、操作权限、质量基线、评测体系与运行反馈。它能够在自己的责任范围内完成问题分析、方案设计、代码修改、测试验证和运行观察，并对这些活动形成连续的认知。

这里所说的“拥有上下文”，不只是给 Agent 写一段更长的系统提示词。一个系统的代码、设计文档、自动化脚本、测试用例、测试数据和关键决策记录，都应该与系统一起进入 Git 仓库，成为可追溯、可评审、可持续演进的知识资产。系统 Agent 启动任务时，可以从这套版本化资产中取得与当前问题有关的事实，而不必每次都等待人重新讲解系统。

Git 仓库保存能够被团队共同检验的系统事实，专属记忆则保存 Agent 在长期工作中形成的历史经验和运行反馈。再加上系统自己的 Skills 与权限边界，一个任务实例启动时就进入了这个系统的语境。它面对的不是一段孤立需求，而是需求背后的代码、约束、历史决策和质量标准。

![系统Agent从Git仓库、专属记忆和能力权限中获得系统上下文](https://www.agilean.cn/images/insights/system-agents-not-pipeline-agents/system-agent-context.jpg)

*系统Agent从Git仓库、专属记忆和能力权限中获得系统上下文* 在这个结构里，Plan、Design、Build、Test、Deploy、Maintain 构成系统持续演进的六步闭环。它们不是六个彼此交接的永久 Agent，而是系统 Agent 根据任务需要调用的能力。系统 Agent 可以临时启用规划者、编码者、检查者等子 Agent，也可以调用不同的 Skills 完成工作，但这些临时角色都服务于同一个系统目标，共享同一套系统上下文。

**这背后的变化不是命名方式变了，而是责任结构变了**：过去由不同岗位分别对阶段产物负责，未来由系统 Agent 对一个系统的持续演进负责。

![产品Agent、领域Agent与系统Agent围绕共同业务目标协作](https://www.agilean.cn/images/insights/system-agents-not-pipeline-agents/system-agent-collaboration.jpg)

*产品Agent、领域Agent与系统Agent围绕共同业务目标协作*

## 需求分析将变成多系统智能体协作

有人可能会问：如果不建设需求分析 Agent，需求由谁来分析？

答案是，复杂需求本来就不应该由一个“需求分析 Agent”独立分析。**真正的需求分析，是产品目标、业务规则和多个系统现实之间的一次共同推演。**

例如，一个“优化用户补能体验”的需求，可能同时涉及产品体验、补能业务规则、车机系统、移动端应用、订单系统、会员权益和数据平台。一个通用的需求分析 Agent 即使能够生成一份结构完整的需求文档，也很难独自掌握所有系统的历史决策、接口约束、技术债务和运行风险。

更合理的方式是：产品 Agent 提出用户目标和价值假设，业务领域 Agent 提供规则、概念与约束，相关系统 Agent 分别判断本系统受到的影响、可行路径和风险。它们围绕同一个变更目标协作，最终形成共同的需求理解、跨系统变更契约和各系统的实施方案。

这时，需求分析不再是研发流水线最前端的一道工序，而是一场多智能体参与的决策过程。设计、编码和测试也不再是下游接单，而是各系统 Agent 在自己的上下文中完成价值闭环。

一个需求可能需要多个系统 Agent 协作，但每个系统 Agent 都对自己负责的系统完成从理解意图、设计变更、实现验证到运行反馈的完整闭环。

## Agent实例代表一次具体的工作上下文

讨论到这里，还需要区分“逻辑 Agent”和“Agent 实例”。

一个系统可以拥有一个长期存在的逻辑系统 Agent。它代表稳定的身份、责任边界和能力集合，与系统共同演进。但这不意味着同一时间只能运行一个 Agent 进程。面对多个并行任务，逻辑系统 Agent 可以创建多个任务实例。

每个任务实例对应一次具体工作，拥有自己的任务上下文、选用的 Skills、记忆切片、工作空间、临时权限、资源预算和生命周期。任务结束后，一部分过程信息可以被清理，真正有长期价值的系统知识、决策记录和运行反馈则被沉淀回系统 Agent 的长期记忆。

因此，更准确的关系是：

> **一个系统形成一个长期负责的逻辑系统 Agent；一次具体任务形成一个拥有独立上下文的 Agent 实例。**

这个区分很重要。没有稳定的逻辑 Agent，知识就难以随系统持续积累；没有隔离的任务实例，并发任务之间又容易相互污染，权限和资源也无法得到精细治理。

## 业界正在出现相同方向的信号

“系统智能体”还不是业界统一使用的术语，但越来越多的 Agent 架构开始把长期智能体放在领域、能力和系统边界上。

AWS 在多智能体协作架构中强调由不同领域的专门 Agent 分工，并举出了按按揭业务、商品推荐、订单管理、个性化和故障处理划分 Agent 的例子。每个 Agent 可以拥有自己的工具、知识库和安全约束，而不是只对应一段处理工序。

微软提出 Hub Agent 与 Domain Agent 的组合方式：单一领域的问题交由相应的领域 Agent 处理，跨领域问题再由 Hub 协调多个 Agent，并通过能力发现、Agent Card 和任务契约完成协作。

Palantir 则把 Agent 建立在企业的 Ontology 和 operational domain 之上，让 Agent 直接继承业务对象、动作、数据、逻辑和权限。同时，它把 Agent 定义与具体任务 Session 分开：一次任务拥有自己的上下文、状态和事件历史。

这些实践尚未给出一个统一答案，但方向越来越清晰：**企业级 Agent 不是漂浮在业务系统之上的通用聊天机器人，而会逐渐成为带着领域上下文、系统能力和治理边界的责任主体。**

当然，Planner、Coder、Tester 这样的角色型 Agent 仍然有价值。它们适合成为一次任务中的临时工作者、专业检查者或内部协作模式。**问题不在于能不能使用这些 Agent，而在于我们是否把它们错误地当成了企业 Agent 架构最上层、最稳定的边界。**

## 不要让AI复制昨天的组织

AI Native 研发体系不应该从“每个岗位配置什么 Agent”开始，而应该先回答几个更根本的问题：

企业有哪些需要长期负责和持续演进的产品、业务领域与系统？哪些上下文应该被长期保存？哪些能力应该围绕同一责任主体组合？不同责任主体之间又通过什么契约协作？

想清楚这些问题以后，我们可能会得到一幅完全不同的 Agent 地图：产品 Agent 负责价值目标，业务领域 Agent 维护领域知识和规则，系统 Agent 负责系统的完整生命周期；Plan、Design、Build、Test、Deploy、Maintain 成为它们可以灵活组合的能力；每一次任务则形成一个受到上下文、权限和资源约束的 Agent 实例。

过去，我们围绕岗位组织工作，再通过流程把岗位连接起来。未来，我们可能围绕产品、领域和系统组织智能体，再让人和智能体共同对价值结果负责。

所以，在开始建设下一个需求分析 Agent、编码 Agent 或测试 Agent 之前，也许值得先停下来问一句：

> **我们是在建设面向未来的智能体，还是在让 AI 复制昨天的组织？**

---

## 参考资料

1. [AWS：Multi-agent collaboration](https://docs.aws.amazon.com/en_us/bedrock/latest/userguide/agents-multi-agent-collaboration.html)
2. [AWS：Multi-Agent Orchestration on AWS](https://docs.aws.amazon.com/solutions/multi-agent-orchestration-on-aws/)
3. [Microsoft：Multi-agent patterns](https://learn.microsoft.com/agents/architecture/multi-agent-patterns)
4. [Microsoft：Connecting agents](https://learn.microsoft.com/en-us/microsoft-365/copilot/employee-self-service/connecting-agents-overview)
5. [Palantir：AIP architecture](https://www.palantir.com/docs/foundry/architecture-center/aip-architecture)
6. [Palantir：Agent Stack](https://www.palantir.com/docs/foundry/aip/agent-stack)

Agilean 方法论

## 本文相关的 Agilean 方法框架

- [AI 原生研发组织](https://www.agilean.cn/methodology/ai-native-five-roles/)：AI Native 五角色模型；Prototyper、Productizer、Challenger、Beautifier、Grower，按五类关键结果重新划分研发责任。
- [AI 组织转型](https://www.agilean.cn/methodology/ai-organization-transformation-5-2/)：5+2 AI组织转型新范式；五个主体变化加两个支撑系统，把个人 AI 提效转化为团队、产品线和组织的系统效能。

## 订阅洞见

新文章发布时，通过邮件第一时间收到。

推荐阅读

- [AI Native研发岗位模型：五种新角色与组织责任重构](https://www.agilean.cn/insights-new/ai-native-rd-role-model/)
- [AI 编程中的 Plan Mode：计划仍然需要，但不必逐行细看](https://www.agilean.cn/insights-new/plan-mode-in-ai-coding/)
- [为什么本体会成为企业 AI 的核心基础设施？](https://www.agilean.cn/insights-new/enterprise-ontology-infrastructure/)

---

来源：[你可能建错了智能体：建设系统智能体，而不是复制研发工序](https://www.agilean.cn/insights-new/system-agents-not-pipeline-agents/)（更新于 2026-10-17）