上个月一个团队找我聊数字员工落地。
他们已经有 12 个 agent 在跑了。销售助手、客服助手、HR 问答、会议纪要……每个都是独立项目，独立部署，独立维护。
CTO 说：「我们想扩到 200 个。」
我问：「现在 12 个的权限怎么管的？」
他愣了一下：「每个 agent 一个 API key，配在环境变量里。」
「记忆呢？A 部门的 agent 会不会读到 B 部门的会议纪要？」
「……应该不会吧。」
「两个 agent 对同一件事判断冲突了，谁说了算？」
沉默。
12 个靠人盯，200 个靠什么？这不是「多部署几个」的问题。这是架构问题。
架构师的价值不是「设计得好」
很多人对架构师的理解停留在「画系统图的人」。
但架构师真正的价值是： 让错误的决策变贵。
好的架构让团队在早期就被迫面对正确的约束——接口边界、数据流向、扩展点。坏的架构（或者没有架构）让所有错误都很便宜，直到某天突然变得极其昂贵。
AI 产品尤其如此，因为三个结构性原因：
第一，不确定性是内建的。 传统软件的输入输出是确定的，AI 产品的核心链路是概率性的。架构要解决的不是「怎么调通」，而是「怎么让不确定性可观测、可回退、可局部替换」。
第二，迭代速度是生死线。 模型能力半年一变，prompt 和 agent 策略周级迭代。如果架构把模型选择、评估、数据流焊死在一起，每次迭代都是全栈手术。
第三，评估即基础设施。 传统产品靠测试用例，AI 产品靠 eval。eval 不是「加个脚本」，它需要架构级的数据管道、版本管理、回归对比。没有这层，团队只能靠「我觉得变好了」来决策。
我在 好的 Harness 不挑笔 里讲过，好的工程约束不关心具体用哪个模型、哪个 agent loop。架构师做的事本质上是一样的——把「会变的」和「不能变的」分开，让变化发生在正确的边界内。
很多人忽视这个岗位，本质上是因为架构的收益是负熵——你看到的是「没发生的灾难」。老板看到的是功能上线速度，看不到的是三个月后因为耦合导致的重构成本。
数字员工规模化：三层架构问题
当 AI 产品从「一个 agent 跑通 demo」走向「一千个数字员工在组织里协同工作」，架构师面对的问题完全变了性质。
我在 数字分身和数字员工的分界线 里说过，从分身到员工，身份、权限、审计、责任归属全部要重来。但那篇文章讲的是「为什么要重来」。这篇讲的是 重来时，架构师具体要解什么题。
┌─────────────────────────────────────────────────────┐
│ 治理层 Governance │
│ 预算域 · Eval Pipeline · 生命周期管理 │
├─────────────────────────────────────────────────────┤
│ 工程层 Engineering │
│ 编排 · 记忆隔离 · 可观测性 · 故障熔断 │
├─────────────────────────────────────────────────────┤
│ 组织层 Organization │
│ 身份模型 · 岗位-权限-数据域 · 汇报关系 │
└─────────────────────────────────────────────────────┘
一、组织层：数字员工是「人」还是「工具」？
这是第一个架构分叉。
身份模型。 数字员工在组织里有没有 userId？能不能被 @、被分配待办、出现在审批链里？如果只是 API key + webhook，它永远是工具，无法进入协同流。我在 你的下一个下属，不需要工位 里讲过，没有岗位说明书的数字员工就是「什么都会但什么都不会」——而岗位说明书的前提是，它在组织模型里有一个位置。
权限边界。 一个数字员工能看哪些群、读哪些文档、代谁发消息？权限不是「全有或全无」，而是跟岗位绑定的。架构上需要一套 岗位-权限-数据域 的映射，而不是每个 agent 单独配 token。
汇报关系。 数字员工犯了错，谁负责？架构上必须有明确的 owner 和 escalation path。没有归属的数字员工就是组织里的幽灵。
这三个问题不是「产品需求」，是 架构约束。如果组织模型里没有这些一等公民的抽象，后面所有工程实现都是在沙子上盖楼。
二、工程层：从「跑通一个」到「跑稳一千个」
编排与自治的平衡。 1 个 agent 可以全自主，100 个 agent 必须有分工、委派链、冲突仲裁。架构要回答：谁决定任务分给谁？两个 agent 对同一件事的判断冲突时怎么办？这不是 prompt 能解决的——你需要一个编排层，它知道每个 agent 的职责边界、能力等级、和升级路径。
状态与记忆隔离。 每个数字员工需要持久记忆，但跨 agent 的记忆共享必须受控。A 部门的数字员工不应该「记得」B 部门的会议纪要。这是架构问题，不是 prompt 问题。记忆存储必须按数据域隔离，共享必须走显式授权。
可观测性与可重放。 规模化之后，「它为什么做了这个决定」必须能回答。需要完整的决策链路日志：输入 → 推理 → 工具调用 → 输出，且可重放、可对比。没有这层，出了事只能猜。
故障隔离与爆炸半径。 一个 agent 幻觉了，不能级联污染下游。需要熔断、沙箱、灰度发布。跟微服务治理同构，但更难——因为 agent 的「错误」不是 500，是「看起来对但实际错」。传统监控抓不住这种故障，你需要语义级的健康检查。
三、治理层：规模化的真正瓶颈
成本非线性增长。 10 个 agent 的 token 成本不是 1 个的 10 倍，可能是 50 倍（基于多 agent 项目的经验估算）——因为 agent 间通信、重复推理、上下文膨胀。架构上需要 预算域 和 推理缓存层。没有预算域的 agent 集群，就像没有成本中心的财务系统——月底一看账单，没人知道钱花在哪了。
评估即运营。 规模化之后不能靠人肉看效果。需要自动化的 eval pipeline：每个数字员工有「绩效指标」，定期跑回归，劣化自动告警。我在 招 Agent 工程师，我第一个看的不是技术 里提到，AI 原生的工程师会把 eval 当基础设施而不是事后补丁。架构师要做的，是让 eval 成为系统的一等公民，而不是某个工程师的个人习惯。
生命周期管理。 入职（配置 + 权限开通）→ 培训（prompt/策略迭代）→ 考核（eval）→ 调岗（换模型/换职责）→ 离职（权限回收 + 记忆归档）。这不是比喻，是架构上真的要实现的流程。每个状态转换都需要对应的 API、审计日志、和回滚能力。
一个判断
有人会反驳：模型能力在快速进步，这些架构问题会被更强的模型自动解决。
恰恰相反。 模型越强，agent 自治度越高，架构约束越重要。
一个只能回答问题的 chatbot，不需要权限隔离、不需要编排层、不需要生命周期管理。一个能自主决策、跨系统操作、代组织行事的数字员工，这些全是刚需。
模型每进步一代，agent 能做的事就多一圈——能调的工具更多、能访问的数据更广、能自主决策的链路更长。能力边界每扩一圈，架构要兜住的爆炸半径就大一圈。这不是「模型够强就不需要架构」，而是「模型越强，没有架构的代价越高」。
模型能力解决的是「能不能做」，架构解决的是「敢不敢让它做」。
写在最后
数字员工规模化的本质不是「多部署几个 agent」，而是在组织里建立一套让 AI 可管理、可问责、可演进的治理架构。
技术难度不在模型，在工程；工程难度不在单点，在系统。
如果你正在做数字员工产品，第一个该招的不是 prompt engineer，是架构师。
你在规模化 agent 的过程中踩过什么架构层面的坑？欢迎留言讨论。