别把 AI 当“赛博朝臣”：Agent 架构的本质是无状态函数调用

最近在开发者社区和 GitHub 上，涌现出大量极具噱头的 AI 项目：“一人公司指挥 10 个 AI 员工”、“三省六部制赛博朝廷”。这些项目往往配有精美的组织架构图，每个 AI 被赋予了不同的头像、人设（比如“正一品中书令”、“资深产品经理”），甚至还有复杂的上下级汇报机制。

这类项目往往能斩获极高的流量和过万的 Star。但从严肃的底层工程视角来看，我们需要指明一个残酷的真相：如果你真的想用 AI 落地高复杂度的生产力任务，这种“拟人化团队”的架构思路是存在致命缺陷的。

这种设计提供的并不是工程可靠性，而仅仅是让用户体验了一把“当老板”的权力幻觉。

一、 拟人化陷阱：管理学幻觉对工程的污染

将 LLM（大语言模型）包装成“员工”，本质上是利用了人类几千年演化出的社交本能。我们的大脑习惯于用分岗位、定职责的方式来处理复杂任务。

在那些动辄用上千行代码去维持“朝廷氛围感”的开源项目中，AI 被强制要求输出带有性格色彩的口头禅，甚至要维护 12 个 Agent 之间的事件总线（Event Bus）、Redis 队列和看板同步。同一个基座模型，仅仅换了不同的 System Prompt（系统提示词），就被强行当成具备不同底层认知的独立个体。

为了维持这种“角色扮演”，系统必须耗费海量的 Token 来处理 Agent 之间的“通信协议”和“防注入机制”（例如警告 Agent A 不要试图越权修改 Agent B 的状态）。这在系统设计上是极度冗余的。

当你把精力花在维持多个 Agent 之间的“沟通顺畅”时，驱动你写代码的动力已经不再是“把活干好”，而是维持一种虚拟的控制欲。这种将管理学照搬进软件工程的做法，严重偏离了 Agent 的核心技术路径。

二、 核心范式转移：Agent 不是独立员工，而是函数调用

在 AI 时代，真正的系统工程痛点不是“如何分配角色”，而是“如何精准地打包上下文，进行高效隔离与流转”。

我们需要确立一个底层认知：Agent 本质上是一次包裹着特定上下文的函数调用（Function Call）。 这一认知可以拆解为三个维度的架构设计：

1. 输入层：上下文即“岗位”

在微服务或底层通信基建中，我们极其强调数据流的隔离（就像在处理交易所 WebSocket 接口时，必须将高频的市场数据流与深度的订单簿数据流进行物理隔离，以防止阻塞和数据污染）。

对 AI 也是同理。你给子智能体（Sub-agent）的输入，不应该是虚无缥缈的“岗位描述”，而是一个纯净的工作上下文（Context Payload）：任务目标、依赖数据、判断标准、输出结构。一个干净、隔离的上下文，本身就定义了这个 Agent 的全部功能。 冗余的历史对话痕迹只会造成模型的注意力涣散（Attention Dilution）。

2. 输出层：用完即弃（Stateless）

优秀的 Sub-agent 应该是无状态的。主线程将其拉起，传入参数，它在独立的容器或内存空间中完成推理、尝试、报错、修正，最后向主线程返回一个标准化的结果（例如：bool: true, 或者一段 JSON 数据）。

任务结束，Agent 即刻销毁。它不需要“持续在线”，不需要占用主线程的注意力资源，更不需要在庞大的事件总线里和其它 Agent 闲聊。

3. 决策层：单一的中枢线程

主线程应该是唯一的决策引擎。系统架构应当是主线程串行或并发地拉起不同的函数（Agent），收集结果后决定下一步走向。绝不能让多个平行的 Agent 在缺乏绝对中心的情况下互相协商、投票，最后丢给主线程一团难以解析的非结构化残局。

三、 真实的“分工”：按算力模型，而非角色标签

如果我们抛弃了“产品经理 Agent + 开发 Agent + 测试 Agent”这种可笑的拟人化切分，真正的系统级分工应该怎么做？

答案是：按任务的上下文边界和所需模型的能力档位进行拆分。

• 轻量级数据清洗/格式转换：打包极小的上下文，高并发调用成本极低的端侧或小参数模型。
• 深层次逻辑验证/代码 Review：打包核心代码片段，调用最顶级的 SOTA（State-of-the-Art）大模型进行深度推理。

正确的工程维度始终是：这个节点需要吞吐多大的上下文？需要重试几次？应当路由给哪一个参数量级的模型？

四、 行业的底层共识：收敛复杂度

这并非少数派的偏见，而是目前全球顶尖 AI 团队在踩过无数坑后形成的架构共识：

• Anthropic (Claude 团队) 明确指出：赢家不是搭建了最复杂多 Agent 系统的人，而是系统最贴合实际需求的人。只有在能显著提升效果时，才应引入复杂度。
• Cognition AI (Devin 团队) 在其工程实践中强烈建议避免滥用平行 Multi-Agents。他们推荐“单线程线性 Agent”，强调子节点绝不能与主节点并行干扰，从反面论证了上下文隔离的重要性。
• OpenAI Swarm 作为轻量级框架，其核心设计哲学就是“调用之间无状态（Stateless between calls）”。只有 agent 和 handover（移交）两个原语，没有花哨的黑板模式或复杂的异步看板。

结语：让工程回归工程，让玄学止步于提示词

在提示词工程（Prompt Engineering）中，加一句“深呼吸”、“相信自己”或许能激发大模型的某些参数特征，这种带有玄学色彩的调优无可厚非。但底层的系统架构，必须建立在严密的科学与工程逻辑之上。

当你在本地部署或设计自己的 AI Agent 框架时，不要去思考“我需要构建一个怎样的虚拟团队”。

尝试以一个架构师的冷峻视角来审视系统：我有一个主线程在维护状态机；我将不同的任务切割成高度内聚、低耦合的上下文数据包；我将它们以无状态函数的形式抛给最适合的模型节点；结果返回，节点销毁，干脆利落。

放弃对“赛博权力”的低级幻想，将精力聚焦于“上下文形状”的雕琢，你与 AI 协作的工程质量才能真正实现越级突破。