把 Agent 当企业来设计（1）：一件事，是怎么被交付的

最近 DeepSeek Harness 团队发布了一篇架构文章——Super-agent 设计探索：迈向更自主的 Agent 系统。

我尝试从一个企业运作的角度来理解一下这篇技术文章。

这篇文章提到，现有 Agent 以单个会话为基本单位，而人通常只能同时跟进 3 到 5 个会话。所以单任务的上限取决于模型，多任务的上限取决于人的注意力。仅靠 CLI、MCP 或连接器做简单扩展，也绕不开三个问题：单会话阻塞、多任务上下文混乱、设备离线即停止。

这就像一个没有管理结构的小团队：所有事都压在一个人的脑子里，他一边接着电话，一边还要亲自干活。

那么一家公司是怎么组织起来，顺利运作的？

一个对外窗口：客户只面对客户经理/销售/项目团队，不需要知道内部谁在做什么。 按项目/业务分组：项目组/业务组只管自己的客户和任务，互不干扰，也不直接对别的业务客户说话。 项目群直达：同一个项目的后续沟通直接进群，不必每条都经过老板。 专人督办：有人不做业务，只看事情是否真的在往前走。

这四个安排解决的是同一个问题：让有限的管理注意力，只花在真正需要判断的事情上。

这篇文章在讨论双层架构（如何同时维护全局连续性和高并发执行时，恰好描述了两种极端方案的代价，与企业的经验完全一致：

所有事都交给同一个会话：上下文最连续，但串行执行慢，多件事的中间细节混在一起，效果也会变差。这相当于所有客户都由同一个人从头到尾服务。

每件事都新开一个独立会话：吞吐最高，但任务之间并不完全独立时，结果会彼此割裂，多个会话各自向用户回复，交互也会混乱。这相当于每个客户同时被好几个同事联系

Super-agent 的逐项对应

Router 层是客户经理。 它常驻、承接所有入口的人类交互，所有跨任务的信息与决策都在这里汇总。为了避免它成为瓶颈，它不直接执行具体任务，甚至可以不配 Bash 工具。

Router 的任务往往没有想象中复杂，较轻量的模型常常就够用。

Worker 层是项目组。 每个 Worker 上下文隔离，挂载完整的执行工具，专注单一任务，因此通常配置能力最强的模型。Worker 不直接与人类交互，只向 Router 汇报，由 Router 统一回复用户。

必要时，Worker 内部还可以再创建 Subagent，这对上层是透明的。

订阅与直通是项目群。 同一个 GitHub Pull Request 或同一个 IM 话题下的连续事件构成一条 Thread。Worker 订阅 Thread 后，后续事件由程序直接发给它，不再经过 Router。一个 Thread 也可以被多个 Worker 同时订阅，它们收到相同的通知，有机会自行发现并解决冲突，不必点对点通信，就像两个项目组在同一个共享项目群里协作。

事件过滤是前台与秘书。 真实的群聊与代码平台里，绝大多数消息不需要 Agent 介入。文章用两级过滤：先由程序规则筛掉大部分无关消息，再由模型根据用提示词写成的策略，判断剩下的候选事件是否需要行动。

Watchdog 是督办。 一个独立于主系统的会话，由定时消息驱动，既处理基础设施故障，也判断各个 Worker 是否有实质进展。

这模拟了一个成熟组织的运作方式。