过去，我们设计软件架构时，通常会考虑业务领域、系统复杂性、模块职责、团队分工和人员协作。模块由谁负责、团队之间如何交接、接口由谁维护，往往会影响架构最终长成什么样。

面向 Agent 的架构拆解：从组织协作到任务协作

一个值得重新提出的问题

当 Agent 开始承担越来越多的软件研发工作时，一个值得重新提出的问题是：

软件架构是否需要从面向人的组织协作，进一步走向面向 Agent 的任务协作？

这里并不是说传统架构只服务于组织，也不是说 Agent 会取代人类开发者。模块化、分层、领域驱动设计和微服务，本来就在解决复杂性、变更隔离和系统演进问题。变化在于：当执行开发任务的主体从人类团队扩展到大量 Agent 时，任务如何被理解、分解、并行执行、验证和组合，可能需要成为架构设计中一个更明确的维度。

由此可以提出一个研究方向：面向 Agent 的架构拆解（Agent-Oriented Architecture Decomposition）。

它关注的不只是系统由什么模块组成，还关注这些模块能否支持独立执行、独立验证和可靠组合的工作单元。

一、从组织结构，到软件结构，再到任务结构

先区分三个相关但不等价的概念。

1. 组织结构：谁负责什么

组织结构围绕团队、岗位、专业分工和管理职责组织协作。它回答谁对某项工作负责，谁有决策权，跨团队的事项如何协调。

2. 软件结构：系统由什么组成

软件结构围绕领域、模块、接口、数据流和运行时职责组织代码。它回答系统由哪些部分构成，各部分如何依赖，以及变化如何被隔离。

3. 任务结构：工作如何被执行

任务结构围绕前置条件、依赖关系、执行权限、验收标准和交付边界组织工作。它回答一项工作能否独立开始，哪些工作可以并行，什么条件下才算完成，以及失败后如何恢复。

这三种结构并不天然一致。

例如，一个支付业务可能由支付团队负责，但代码横跨订单服务、账户服务、数据库和消息系统。团队职责是一种边界，代码模块是另一种边界，某次需求的开发任务又是第三种边界。

人类开发者可以通过会议、经验、口头沟通和临时协调跨越这些边界。Agent 也能读取文档、调用工具、修改多个模块，但当多个 Agent 同时执行任务时，依赖隐式知识和临时协调的成本可能迅速上升。

因此，值得探索的方向不是让每个模块机械地对应一个 Agent，而是让软件结构与任务结构建立更明确的映射关系，同时保留合理的领域边界。

康威定律：软件架构会映射协作结构

这里可以引入一个经典的软件架构观点：康威定律（Conway's Law）。它通常被概括为：设计系统的组织，其沟通结构会反映在所设计的系统结构中。

这并不意味着组织结构机械地决定软件架构，而是说，团队之间的信息流、协调成本和职责边界，往往会影响系统模块如何划分、接口如何定义，以及哪些部分最终形成相对独立的子系统。

例如，若前端、计费和渠道团队各自拥有独立的交付节奏，系统可能逐渐形成对应的模块边界；若多个团队需要频繁跨边界协商，一个名义上分层清晰的系统，也可能出现复杂的接口依赖和集成摩擦。

从这个角度看，传统架构设计有一部分是在处理组织沟通结构与软件结构之间的映射。团队边界不一定等于模块边界，但沟通拓扑会持续影响架构的演进。

当 Agent 成为重要的软件生产者时，这个问题会出现新的维度。协作主体不再只有固定团队和岗位，还可能包括动态创建的 Agent、任务规划器、集成 Agent，以及负责验证和审批的角色。它们之间的协作关系，更多由任务依赖、工具权限、上下文共享、接口契约和验证流程决定。

因此，可以在康威定律的启发下提出一个面向 Agent 的延伸假设：

如果传统系统的结构会受到组织沟通结构的影响，那么 Agent 参与的软件生产，也可能让最终的软件结构受到任务依赖拓扑与 Agent 协作拓扑的影响。

这里需要谨慎：这是一种基于康威定律提出的研究假设，不是康威定律原本已经证明的结论，也不意味着每个 Agent 都应该拥有一个模块。Agent 可能是临时的执行者，今天由一个 Agent 承担的任务，明天也可能由另一个 Agent 完成。真正值得长期固化的，仍然是稳定的领域边界、接口契约和系统不变量，而不是某次运行中 Agent 的临时分工。

由此，面向 Agent 的架构拆解不应只是把过去的团队边界换成 Agent 边界，而应该进一步考察三种结构之间的关系：

• 组织结构： 人类团队、职责和决策权如何分布。
• 软件结构： 领域模块、接口和依赖如何组织。
• 任务与协作结构： 工作如何分解、任务如何依赖，以及执行单元如何协作与验证。

这三者不必完全重合，但如果它们之间长期存在错位，就可能产生等待、重复协调、接口争议和集成返工。面向 Agent 的架构设计，正是要让这些关系更加显式、可观察，并能够根据执行反馈持续调整。

二、面向 Agent 的架构，不是把代码拆得更细

一个常见误区是认为：为了提高并行度，只要把系统拆成更多模块、更多插件，或者更多微服务就可以。

实际上，模块数量和并行能力没有简单的正相关关系。拆分过细会增加接口数量、依赖管理、集成和版本协调成本；模块看似独立，如果仍共享大量状态、公共文件或隐式约定，也很难真正并行。

一个更有意义的问题是：

一个模块或任务，能否被一个执行单元在明确约束下独立完成，并由外部机制验证结果？

我认为至少需要考虑四个条件。

1. 边界清晰：知道自己可以修改什么

任务需要有明确的代码所有权、依赖范围和权限约束。Agent 不应该为了完成局部需求，随意修改无关的公共模块。

可采用的工程机制包括模块所有权、独立工作区、受控文件范围、分支隔离和代码审查规则。

2. 契约明确：知道自己必须实现什么

接口契约不应只有函数签名，还应覆盖输入输出语义、异常行为、数据一致性、权限和兼容性要求。

可采用类型定义、Schema、版本化接口、前置条件、后置条件和契约测试，让不同 Agent 不必了解彼此的内部实现，也能协同开发。

3. 结果可验证：知道什么才算完成

不能只依赖 Agent 自己声称任务完成。任务需要有可以外部检查的验收条件，例如单元测试、契约测试、类型检查、静态分析、安全扫描和集成测试。

人工评审依然重要，但不应该成为所有任务唯一的验证方式。

4. 依赖可管理：知道何时可以并行

如果两个任务依赖同一个尚未确定的接口，它们就不是真正独立的任务。合理拆解需要显式表达依赖，并尽量减少不必要的同步。

任务 DAG、接口先行、Mock、版本化契约和合并门禁，都可以帮助降低等待与返工。

因此，一个适合 Agent 的任务单元，不是代码量足够小的单元，而是具有清晰边界、明确契约、可验证结果和可管理依赖的工作单元。

三、从职责模块到可执行任务单元

传统模块化经常以领域职责作为首要拆解依据。例如，Token 中转站可以划分为用户管理、渠道管理、模型调用、计费、用量统计和管理后台。

面向 Agent 的设计还需要继续追问：这些模块是否能进一步形成独立交付的任务？模块之间需要什么契约？哪些任务可以在其他模块尚未完成时先行开发？

以计费功能为例，可以拆出以下任务：

• 定义账务模型与计费接口。
• 实现扣费和幂等处理。
• 实现用量记录与存储适配。
• 编写并发扣费、失败重试和账务一致性测试。
• 完成与模型调用链路的集成验证。

这些任务未必全部独立。例如，账务模型和计费接口需要先形成稳定契约，扣费实现与测试随后可以并行推进；跨模块集成则需要等待相关实现达到可验证状态。

这意味着，任务拆解不能只看业务名称，还要分析依赖关系、共享资源和验证条件。

领域边界与任务边界不必完全重合

领域边界帮助系统保持业务语义一致；任务边界帮助工作能够独立执行。两者需要对齐，但不必一一对应。

一个领域模块可以包含多个并行任务；一个跨领域任务也可能需要多个模块协同完成。架构设计的目标不是强行让两种边界完全一致，而是显式表达它们之间的映射和依赖。

四、架构的核心对象，可以从模块扩展到「可执行契约」

传统架构文档通常描述模块、依赖、数据流和部署方式。这些信息有助于人理解系统，但通常不足以直接支撑 Agent 安全地完成开发任务。

如果架构要成为 Agent 协作的基础设施，就需要进一步描述模块或任务的执行契约。

例如，Token 中转站的计费模块可以有这样的契约。

Billing Contract：计费模块示例

职责

对已验证的模型调用记录执行计费，保证同一业务事件不会被重复扣费。

输入

• 租户 ID
• 业务请求 ID
• 模型用量记录
• 计费规则版本

关键约束

• 相同业务事件重复提交时，不得重复扣费。
• 不允许跨租户读取或修改账务数据。
• 失败重试不能破坏账务一致性。
• 计费规则版本必须可追溯。

输出

• 计费结果
• 账务流水 ID
• 明确的成功、失败或待处理状态

验收条件

• 重复请求测试通过。
• 并发扣费测试通过。
• 事务失败与重试测试通过。
• 租户隔离测试通过。

变更权限

• 可以修改计费插件及其专属测试。
• 修改公共账务接口需要经过 Core 维护者审核。

这份契约不只是给 Agent 阅读的说明书。它可以被转换为不同的机器可消费信息：

契约内容	可用于什么
类型与 Schema	生成接口骨架、校验输入输出
前置条件与后置条件	检查任务是否符合业务约束
验收标准	生成测试、判断任务是否完成
文件与权限边界	限制 Agent 的修改范围
依赖与版本信息	安排任务执行顺序
错误语义	统一重试、回滚和异常处理

由此，架构不再只是供人理解的静态文档，而可以成为 Agent 规划、执行和验证工作的输入。

这里需要一个限定：不是所有架构信息都能完全形式化。业务目标、设计取舍和复杂领域知识仍然需要自然语言、人工判断和持续修订。合理的方向是让可验证的约束尽可能机器可读，而不是试图把整个系统设计完全转化为配置文件。

五、插件化为什么有助于多 Agent 并行开发

插件化是实现任务隔离的一种方式，但不是唯一方式。它的价值不在于把所有功能都做成插件，而在于把变化点与稳定核心分离。

一个支持多 Agent 开发的插件架构，通常需要具备以下特点：

• 稳定核心： 负责生命周期、公共接口、配置、错误处理和权限边界。
• 独立扩展点： 每个插件具有明确职责、目录边界和输入输出契约。
• 独立验证： 插件能够在 Mock 或测试环境下完成主要验证。
• 受控集成： 公共接口变更、依赖升级和跨插件行为通过统一流程审核。
• 明确所有权： 不同 Agent 的修改范围尽可能不重叠。

以 Token 中转站为例，可以考虑将渠道路由、计费、用量存储、鉴权策略和可观测性设计为不同扩展点。

不同 Agent 可以分别实现渠道策略、计费逻辑、存储适配和风控策略，而由集成任务负责验证请求从鉴权、路由到计费的完整链路。

但这只是目标架构示例，不代表现有的 Bifrost Gateway 已经具备所有这些插件接口。具体改造仍需要先检查现有模块、请求生命周期和扩展能力，再决定哪些接口可以复用，哪些需要新增。

插件化不等于天然隔离

如果所有插件仍然修改同一个公共注册表、共享数据库表，或依赖频繁变化的公共接口，冲突依然会发生。

因此，多 Agent 架构需要同时设计模块边界、代码所有权、契约版本和集成流程。插件只是隔离机制的一部分。

六、把架构与 Agent Runtime 连接起来

当模块边界、任务依赖和执行契约明确之后，架构就可以进一步成为 Agent Runtime 的任务规划依据。

这时需要区分两个角色：

• 架构描述任务空间。 它定义模块、接口、约束、依赖和可执行边界。
• Agent Runtime 调度执行。 它根据当前状态选择可执行任务，分配 Agent，管理工作区，收集结果并触发验证。

可以形成这样的闭环：

1. 用户提出目标和验收要求。
2. 规划器读取架构信息，分析依赖与风险。
3. 任务分解器生成任务 DAG，并识别可并行任务。
4. Runtime 为不同任务分配 Agent 和独立工作区。
5. Agent 按契约实现代码，并运行局部测试。
6. 集成阶段验证跨模块行为。
7. 根据测试和运行结果决定合并、重试、回滚或重新规划。

这会降低 Runtime 完全依赖大模型临时推理来处理所有工程细节的压力。它可以利用结构化的模块信息、任务状态和验证规则，减少重复探索和不必要的协调。

当然，架构无法预先知道所有未来任务。遇到新需求时，规划器仍需分析影响范围，必要时调整任务图，甚至提出新的架构变更建议。架构是规划依据，而不是不可改变的静态约束。

七、稳定架构与动态任务之间的矛盾

如果每次开发任务都重新拆解整个系统，成本会很高；如果架构完全固定，又可能难以适应新需求。

可以将系统划分为三个层次：

层次	主要职责	相对变化频率
稳定架构层	领域边界、核心接口、关键不变量	较低
可组合能力层	插件、适配器、策略、工具和服务	中等
动态任务层	本次需求的任务分解、执行计划和 Agent 分配	较高

例如，计费接口不需要每次开发都重新设计；但增加充值奖励功能时，Runtime 可以动态拆出奖励规则、额度入账、幂等处理和对账测试等任务。

因此，一个重要原则是：

不要为了每个任务动态生成架构，而应该让稳定架构支持动态任务组合。

同时，也不能禁止任务执行反馈影响架构。若多个任务反复因为同一个接口不清晰而返工，或者某个模块总是成为并行开发的瓶颈，这些信号就应该触发架构复盘。Agent 可以提出变更建议，再通过影响分析、测试和审核决定是否修改核心结构。

八、如何评价一种架构是否真正适合 Agent

仅凭模块数量、插件数量或微服务数量，无法判断一个系统是否适合多 Agent 开发。更有意义的是观察任务独立性、集成成本、验证覆盖度和变更影响范围。

1. 任务独立性

一个任务在不等待其他任务实现的情况下，能否开始开发和测试？如果大量任务都依赖同一个未确定的公共接口，系统的有效并行度就会受到限制。

2. 集成成本

独立成果合并时，需要多少人工协调、冲突修复和回归验证？并行执行带来的收益，可能被集成成本抵消。

3. 验证覆盖度

多少验收条件可以自动检查，而不是依赖 Agent 自我判断？可验证性越强，任务就越容易被可靠地交付和重试。

4. 变更影响范围

修改一个模块，通常会影响多少其他模块和任务？影响范围越大，说明模块之间可能存在较强耦合，架构边界或公共契约值得重新审视。

这些指标存在权衡。拆分更多模块可能提高任务独立性，却也可能增加接口数量和集成成本。因此，目标不是无限细分，而是找到适合具体系统的平衡点。

可以用一个概念模型表达这种关系：

有效研发吞吐量 ≈ 有效并行工作量 ÷（执行成本 + 协调成本 + 返工成本）

这不是经过验证的定量公式，而是帮助分析问题的思考模型。它强调：Agent 数量和代码生成速度只是生产力的一部分，协调、集成与返工同样决定最终交付效率。

九、三个层次的研究框架

这个方向可以形成三个相互关联的研究层次。

第一层：架构理论——面向 Agent 的架构拆解

研究模块边界、任务边界、接口契约和可验证性之间的关系。

核心问题包括：

• 领域边界与任务边界应该如何对齐？
• 什么样的工作单元最适合独立执行？
• 如何衡量模块耦合对 Agent 并行度的影响？

第二层：工程方法——面向 Agent 的软件工程

将设计原则转化为工程实践，包括任务 DAG、独立工作区、插件化、契约优先、自动化测试、集成治理和失败恢复。

核心问题是如何让多个 Agent 安全并行，而不因公共代码、共享状态和隐式约定产生大量冲突。

第三层：运行时系统——架构感知的 Agent Runtime

让 Runtime 利用架构信息进行任务分解、执行调度、变更影响分析、失败恢复与结果验证。

核心问题是如何让架构信息真正参与执行，而不只是停留在文档里。

三层之间的关系是：第一层定义设计原则，第二层把原则转化为工程方法，第三层尝试把这些方法自动化。

十、仍然开放的问题

这个方向还需要通过真实工程验证，不能只停留在概念推演。

问题一：任务粒度如何确定？

任务太大，难以并行且失败后返工成本高；任务太小，协调、接口和集成成本又会增加。是否可以根据依赖数量、共享文件、验收成本和变更风险，估算一个任务适合继续拆分还是应该合并？

问题二：任务边界如何与代码边界对应？

有些任务只修改一个模块，有些任务天然横跨多个领域。是否需要显式维护任务与代码所有权的映射，并在任务规划阶段识别潜在冲突？

问题三：契约应当形式化到什么程度？

类型、Schema 和测试可以机器验证，但业务意图、架构取舍和体验要求很难全部形式化。如何在机器可验证与人类可理解之间取得平衡？

问题四：架构如何根据执行反馈演进？

如果系统能够持续记录任务等待时间、冲突率、返工率、测试失败和集成瓶颈，这些数据是否可以用来发现不合理的模块边界？又该如何避免为了追求短期并行度而不断拆分架构？

问题五：并行度的上限在哪里？

当更多 Agent 被加入系统时，哪些任务能够获得近似独立的并行收益，哪些任务会因共享状态和接口依赖而迅速增加协调成本？这个边界需要结合实际项目进行测量。

这些问题也意味着，面向 Agent 的架构不应只是给现有软件工程贴上新标签，而应该通过可重复的工程实验，验证哪些设计原则确实能够提升交付效率和可靠性。

结语：让架构成为智能执行单元的协作基础设施

传统软件架构围绕系统复杂性、业务边界和人的协作方式形成了大量成熟方法。Agent 的出现，并不意味着这些方法失效，而是让我们需要重新审视架构与软件生产过程之间的关系。

当 Agent 成为重要的软件生产者，架构除了描述系统由什么组成，还可以明确任务如何拆分、执行单元如何协作、结果如何验证，以及失败后如何恢复。

从“如何让人按照架构协作”，进一步走向“如何让架构本身支持智能执行单元的协作”。

这不是用 Agent 取代传统架构，而是在传统模块化思想之上增加一个新的设计维度：任务可分解性、任务之间的耦合度，以及系统能够支持的安全并行度。

最终，值得追求的并不是让架构看起来更适合 Agent，而是让系统在真实研发中获得更高的有效并行度、更低的集成成本，以及更可靠的交付结果。