- 近几年更可能出现的情况是：一名员工同时照看多条由系统完成的工作线，人仍然在岗。
- 危险在于员工变成整天点“批准”、却没有真正看内容的人，设计时必须避免这种情况。
- 解决办法是让系统只把有风险的工作挑出来交给人，不必让人逐件检查。
1. 一个人管理多个 AI 智能体（AI Agent）的模式是怎么来的
想象一位轮班主管同时照看六台机器。他不用一直守在每台机器旁边，只需看着控制面板，哪台机器发出异常信号就走过去。管理多个 AI 也是同样的道理。
写给开发团队 · 技术细节
过去的知识工作是串行（Serial）完成的：一个人依次检索资料、写作、分析、排版。智能体可以并行完成其中一部分，例如调研智能体（Research Agent）收集证据，分析智能体（Analysis Agent）比较不同情景（Scenario），内容智能体（Content Agent）生成草稿。使用者的职责就变成设定目标、整合结果，并对最终答案负责。
这种能力并不等于可以无限增加虚拟员工。智能体会用错数据、重复工作，或者产出需要检查的结果。没有体系地增加数量，只会让使用者淹没在审核（Review）里，就像一位主管突然多了一大批新下属，却没有岗位说明书。
2. 按职能建立智能体组合（Agent Portfolio），不要每次从零做起
常见的失误是让一名员工照看好几个毫不相干的系统。他整天都在切换上下文，结果什么都没认真检查。交给同一个人照看的工作，应该属于同一类。
写给开发团队 · 技术细节
把智能体分成个人（Personal）、团队（Team）和企业（Enterprise）三级。个人智能体协助个人工作，没有重要权限；团队智能体使用共享的工作流和知识库；企业智能体对接核心系统，必须有完整的治理（Governance）。
写给开发团队 · 技术细节
建立智能体目录（Catalog），写明发起人（Sponsor）、版本（Version）、数据、工具、成本和服务水平协议（SLA）。团队应该选用已经批准的智能体，避免重复开发，这样能降低回答标准不一和费用分散的风险。没有用户或没有负责人的智能体必须下线（Retire）。
| 智能体 | 职能 | 自主程度 |
|---|---|---|
| 调研（Research） | 检索并总结，附上来源 | 只读 |
| 起草（Drafting） | 根据模板生成文件 | 生成草稿 |
| 运营（Operations） | 按规则更新系统 | 有限写入 |
| 客户（Customer） | 回复或准备回复 | 只发送低风险（Low-risk）回复 |
3. 如何安排任务队列，不让人成为瓶颈
按价值、截止时间和风险设定优先级。智能体不应事事都找人审批：标准情况直通处理（Straight-through），相似的工作批量审核（Batch Review），只有重要事件才打断（Interrupt）人。队列页面要显示需要决定的事项，不必把冗长的结果全部摊开。
写给开发团队 · 技术细节
使用工作包（Work Package），写明目标（Objective）、背景（Context）、约束（Constraints）、交付物（Deliverable）和完成标准（Definition of Done）。周期长的工作，要在智能体花费预算或大量调用工具之前设置检查点（Checkpoint）。避免只下达“分析整个市场”这类宽泛目标，却不给出要回答的决策问题。
像管理人类团队一样设定在制品上限（WIP Limit）。如果使用者同时开了 20 个智能体任务，却来不及检查，处理周期（Cycle Time）会拉长，上下文也会混乱。仪表盘应该显示等待审核的工作、排队时长和已经花掉的成本。
4. 按风险审核，不必每个字都同样细读
写给开发团队 · 技术细节
区分事实（Fact）、计算（Calculation）、判断（Judgment）和文风（Style）。事实必须注明出处（Citation），数字交给计算系统，判断必须写明假设，文风可以抽样（Sampling）检查。送到人手上之前，先用检查清单（Checklist）和自动评测检查内容是否完整。
建立标准范例（Golden Examples）和错误分类法（Failure Taxonomy），例如来源不对、数据过时、计算错误、违反策略（Policy）或措辞不当。审核时记下错误类型，用来改进系统，只改这一件工作是不够的。置信度（Confidence）要看证据是否充分、是否通过规则检查，和文字的语气有多肯定无关。
5. 智能体并行工作时必须设定的限制
- 每个智能体都有独立的身份（Identity），并由一位真人担任发起人
- 遵循最小权限原则，把读取、生成草稿和执行（Execute）分开授权
- 按任务、智能体和用户分别设置调用频率和成本上限（Rate/Cost Limit）
- 涉及资金、个人数据、对外发布和删除的操作需要审批
- 用幂等性（Idempotency）防止重复发送或重复创建
- 日志把任务、工具调用（Tool Call）和结果关联起来
- 紧急停止开关（Kill Switch）和人工后备方案（Manual Fallback）
不要把提示词（Prompt）当作唯一的管控手段，重要的策略必须由模型之外的系统强制执行。让多个智能体互相调用会增加连锁风险，所以要限制调用深度（Depth）、工具和预算，并检测停不下来的循环。
6. “智能体管理者”（Manager of Agents）的一天
早上，经理不看收件箱，先打开成果仪表盘（Outcome Dashboard）：检查智能体夜里处理的工作中出现的三个例外，批量批准标准报告，处理特殊客户的个案，接着同时分派三条调研任务，为定价决策做准备。
写给开发团队 · 技术细节
智能体工作的时候，经理去见客户、开团队会议。下午审阅汇总了证据的简报（Brief），选定情景，再让起草智能体（Drafting Agent）接着生成文件；审批通过后，运营智能体（Operations Agent）更新相关工作。下班前，经理查看失败模式（Failure Pattern），修正知识库里的一处内容，减少第二天的例外情况。
人的价值从亲手完成每个步骤，转向定方向、选证据、做决定和改进系统。所以工作安排里要留出改进系统（System Improvement）的时间，不要一腾出时间就马上塞满新工作。
7. 不会诱导错误使用智能体的 KPI
写给开发团队 · 技术指标
再加上质量（Quality）、单位成果成本（Cost/Outcome）、处理周期和客户影响（Customer Impact）。不要把智能体数量、提示词数量或智能体运行时长当作目标，否则团队可能制造出大量工作和成本，却没有增加价值。要衡量复用（Reuse）和改进（Improvement），看老问题有没有减少。
设定安全的产能区间。一个人能照看多少个智能体，取决于风险和工作的多样性，不能套用同一个比例（Ratio）。销售和财务的情况不同，要根据真实的队列和审核时间来试。
8. 在 45 天内试行新的团队模式
- 选一名能干的员工，以及一个重复工作多的成果
- 按 2–3 种职能建立智能体，权限从只读和起草开始
- 记录产出、人工处理时间（Touch Time）和质量的基线数据
- 在设定在制品上限和审核队列的前提下，试行并行工作
- 通过评测之后，只在标准情况下扩大权限
- 比较产能变化，重新设计岗位说明书
总结：只要每个智能体的工作清楚、队列排好优先级、按风险审核、管控内置在系统里，一名员工就能指挥多个智能体。未来这个角色要管理的是成果和质量，会写提示词并不是重点。公司应该先根据数据试出合适的比例，再考虑把它用于裁员计划。
让一名员工管住多条工作线，又不沦为只会点按钮的人
知道哪类工作要先检查、哪类可以直接放行的，是您自己的团队主管和资深员工。我们帮忙把这些经验转成系统能据以决策的规则，例如各类工作的风险标准、队列的优先顺序、必须停下来等人的条件，以及什么样的结果算合格。规则清楚以后，员工的负担就从逐件检查，变成只对系统挑出来的事项做决定。
为照看多个智能体的人准备的单页系统
我们通常会做一个统一的控制界面，把多个智能体的工作放进同一个队列，按风险和截止时间排序。界面上有批准或退回的按钮，理由会记入决策记录（Decision Log）；还有事先设好的限制，例如单笔金额上限或每小时最多处理多少项工作。我们建议从工作最明确的两三个智能体开始，先用影子模式（Shadow Mode）和人工结果对比，再正式启用，之后一个一个地增加。如果团队里有人正同时从好几个工具接收工作，就可以从这个人的工位开始。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这组术语讲的是，怎样让多条自动化工作线始终处在可检查的状态。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Queue | 等待系统处理或等人决定的工作队列，带有优先级 | 高风险工作排到队列最前面 | 队列按什么标准排序？谁能调整顺序？ |
| Decision Log | 记录谁基于什么理由做了什么决定，便于回顾 | 保存主管否决某一版方案的理由 | 决策理由存在哪里？怎样用来改进？ |
| Rate Limit | 限制一段时间内的工作量或请求数，防止系统超负荷运行 | 限制智能体每小时最多发送一定数量的邮件 | 碰到上限时，系统会停止还是排队？通知谁？ |
| Shadow Mode | 让系统并行运行、与人工结果对比，但暂不真正执行操作 | 智能体在一旁给出建议回答，让员工对比两周 | 哪项指标达标后，我们就结束影子模式？ |
| Kill Switch | 发现问题时立即停止系统运行的开关 | 发现错误时，停止所有给客户发消息的智能体 | 谁有权按下停止键？按下之后，积压的工作怎么处理？ |