你可能建错了智能体：建设系统智能体，而不是复制研发工序
作者：吴穹
最近，不少团队开始规划自己的“智能体矩阵”：需求分析智能体负责理解需求，设计智能体负责输出方案，编码智能体负责生成代码，测试智能体负责生成用例和执行验证。如果把研发流程画成一条流水线，几乎每一个传统岗位旁边，都可以再放上一个 Agent。
这看起来很合理。既然过去由不同岗位完成这些工作，现在就给每个岗位配置一个智能体，甚至让智能体直接替代其中一部分工作。
但这里可能藏着一个根本问题：我们正在用旧组织的地图，建设新世界的智能体。
岗位换成了 Agent，流水线却没有消失；每个环节都变快了，系统交付却未必同步变快；人和 Agent 都在忙，需求仍然要在不同角色之间反复解释，背景知识仍然要反复装载，设计决策仍然可能在编码阶段丢失，测试发现的问题仍然要沿着原来的链条向上追溯。
如果是这样，我们建设的可能不是 AI Native 研发体系，只是一条由 Agent 加速的旧流水线。
按研发工序建设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仓库、专属记忆和能力权限中获得系统上下文 在这个结构里，Plan、Design、Build、Test、Deploy、Maintain 构成系统持续演进的六步闭环。它们不是六个彼此交接的永久 Agent，而是系统 Agent 根据任务需要调用的能力。系统 Agent 可以临时启用规划者、编码者、检查者等子 Agent，也可以调用不同的 Skills 完成工作，但这些临时角色都服务于同一个系统目标，共享同一套系统上下文。
这背后的变化不是命名方式变了，而是责任结构变了：过去由不同岗位分别对阶段产物负责，未来由系统 Agent 对一个系统的持续演进负责。
产品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 复制昨天的组织？