一个入口对多个执行体：协调层的成本要单列｜洹拓科技
一、瓶颈要说成注意力，就得先能被数出来
那篇设计探索文章的起点是一句很朴素的观察：一个开发者通常只能同时跟进三到五个智能体会话，每个会话有独立上下文，人需要记住哪个任务在哪个会话里、当初都交代过什么。据此它把多任务的上限归到人的注意力，而不是模型能力。这个判断对我们有用，但它只有变成能采的数才有决策价值。我们把它拆成三项：同时在跟踪的会话数、需要主动回忆上下文的次数、跨会话传话的往返次数。
采法上，接入前不该靠感受。会话记录本身就是数据源：人主动从甲会话切到乙会话的次数、把同一段背景重新粘进另一个会话的次数、一个临时改掉的方案在几个会话之间来回转述的次数，这三项都能从对话日志里数出来。接入后沿用同一套口径，只是主体换了：原来数人切了几次，现在数协调层主动来问了几次、有多少任务停在“等待人回答”这一栏里。
两个坑要提前说明。第一，前后两段必须用同一批任务组合与同一个接单渠道。缺陷复现、代码审查、功能开发这三类工作对注意力的消耗差别很大，拿混合口径的前段数据去比单一口径的后段数据，结论一定偏。第二，“传话”这一项要连着中途变更一起看。用户临时加需求或改方案时由协调节点统一接住再往下安排，省掉的是人在会话之间来回转述；但如果协调层转述得不清楚，人还是要下探到执行体去确认一次，账面上省了、实际上没省。
二、两本账必须分列，只报完成时间等于藏账
这套架构只分两层。上层是常驻的全局协调节点，统一接收来自群聊、代码托管平台、邮件等多渠道消息，负责接待人、维护跨任务的共享信息、把工作分派下去，自己不写代码；下层是多个执行体，各自维护独立上下文、配齐工具、并行执行具体工作，必要时再调用更下层的子智能体，执行体不与人直接对话，做完把结果报回协调层。两层的模型配置是反着给的：协调节点用便宜的小模型就够，理由在于它手里没有执行工具的权限；执行体侧用最强的模型。
账也要按这两层分列：
- 机器侧账：协调层的决策次数、缓存读取的词元消耗、为隔离上下文而重复携带的那部分输入。
- 人侧账：人实际盯屏与被打断的次数、需要记住的任务位置数、回答协调层提问的次数。
据公开报道，该研究原型在模拟三百条消息、约二十个工作请求的负载下，一半任务在 12.4 分钟内完成、九成半在 15.7 分钟内完成；更要紧的一组对照是，任务完成时间几乎没变，而协调层需要做的决策次数增加约 30%，缓存读取的词元消耗增加约 37%。这组数字来自合成负载与简化环境下的模拟，不是本篇的判断依据，我们借它只论证一件事：“时间不变”不等于“没有代价”。
决策次数为什么是成本，可以从三处看：每一次协调决策都是一回模型调用，进词元账单；它排在派发路径上，进时延链；它还进失败面，每一个决策点都是一个可能判错的地方，判错的常见后果是任务被交给不合适的执行体，或者被重复派发一次。缓存读取词元这一项更难被看见。它的含义是协调层在反复重建全局状态——每次派活之前，都要把跨任务那份共享信息读回来才能判断该给谁。协调节点配小模型省下的是单位推理的价格，省不掉这个读取量，两者相乘才是协调层的真实开销。报道对结果的解读是“让消息少绕一圈，主要省下的是协调过程中的推理开销”，方向与此一致：省的位置在推理链路，不在钟表时间上。
所以在洹拓给客户做这类评估时，交付物是两张表而不是一句话，各自有责任人、各自的采集脚本。把两本账合并成“效率没有下降”，客户在模型调用支出里就会撞见一笔说不清来源的增量。
三、权限切分与入口统一是两回事
运行前提被列得很直白：需要一个专用账号，该账号对目标仓库有开合并请求的读写权限，需要可用的模型调用额度，还要告诉系统在哪里干活、给谁干活。被强调的一条实现取向是执行环境留在本地，代码与凭证不出本机。这几句合起来，就是两层结构里权限最小化的落点：协调节点不持有执行工具与写入凭证，执行体持有。
这条分工至少带来三处实现要求。凭证不外传：协调层的会话记录、共享信息载体里不允许出现执行体的凭据，否则统一入口顺手把最高价值的东西记进了最容易被读到的地方。可撤销的动作集合：每个任务派下去时授予哪些动作要能列举，中途能收，收完仍在跑的执行体要在下一次调用时被挡住，而不是等它自然结束。越权调用的拦截点：要有一个明确的拒绝位置，拦掉“协调节点替执行体直接做一件事”这类请求——这一层一旦为了方便开了口子，两层结构就退化成一层带装饰的直连。
“入口统一”和“权限统一”经常被混为一谈，值得掰开。统一的是消息路由与会话身份：外部世界只需要对一个对话说话。不统一的应当是能力：写入、执行、外发这三类权限按层给。若把权限也一并归到入口上，任何一条被注入到入口的消息，都自动等于一次被授权的操作，攻击面随渠道数量一起放大。
四、专用账号是长期运行主体，要按台账管
事件驱动意味着没人守着开工：监听代码托管平台、可选接入即时通讯群，有人报问题就自动开任务，在独立目录里干完，再回到原对话提交合并请求。这种跑法下，账号不再是某个人的便利身份，而是一个长期存在的运行主体，需要台账字段把它管住。至少要记这几项：账号归属，也就是哪个团队对它的行为负责；权限范围，即哪些仓库、哪些动作；有效期，到期是回收还是续签；被撤销时的残留，即还挂在哪些自动化规则与凭据缓存里；审计字段，把每条任务的来路与去处留住。
审计字段里最容易漏的是主体分离。过去一个合并请求的提出人和执行人是同一个人，两栏合一没有问题；自动化开任务以后，“谁提的”与“谁做的”必须分栏——前者记触发消息的作者与来路渠道，后者记执行体标识、所用模型档位、任务运行的目录与产出落点，发起合并请求的账号单独记一栏。分栏的价值不在追责好看，在于出问题时能一眼看出这是人的一次决定，还是协调层的一次误判，两类问题的处置路径完全不同。
撤销与残留这一项建议单独设一个回查动作。专用账号被停用后，残留一般在三处：仓库侧的授权关系、外部渠道里配置的触发器、共享信息里没清掉的引用位置。台账应当把这些位置列成清单，每次变更后核验一遍，而不是等下一次故障时靠人回忆。
五、共享层与执行体本地之间，画一条两轴的线
官方给出的设计目标大意是：尽量少占用人的注意力、尽量多给价值。落到实现上，最难的一致不是模型档位，而是上下文的分界。协调节点要维护跨任务的共享信息，执行体要各自维护独立上下文，两句话同时成立才有意义：提到共享层的东西越多，隔离就越名存实亡；留在执行体本地的东西越多，协调层就越只能靠人来补背景。
我们的判法是按两轴分格，先问是否跨任务复用，再问是否含敏感内容。
| 分类 | 判定 | 处置 |
|---|---|---|
| 跨任务复用，不含敏感 | 任务清单与状态、对外承诺的接口约定、验收口径、客户给的关键约束 | 放共享层，允许各执行体读取，变更由协调节点记录版本 |
| 跨任务复用，含敏感 | 环境地址、内部标识、能定位到具体客户的数据 | 摘要化后进共享层，原文留在执行体本地，摘要里只保留可核对的引用编号 |
| 不跨任务，不含敏感 | 本次复现的步骤、评审的改动范围、中间结论 | 留在执行体本地，任务结束即可释放 |
| 不跨任务，含敏感 | 凭据、私有样本、用户个人信息字段 | 只留在执行体本地，随任务销毁，不进入任何共享载体与日志 |
这张表用起来有两个反复出现的老问题。第一个是引用编号要真能回查，摘要一旦和原文脱钩，下游执行体会照着摘要做出与原文不符的判断，而且错得很自洽。第二个是共享层的写入权：谁都有背景要说，和谁都有权改背景，是两件事。我们倾向让执行体只能追加结论、不能改写全局约定，改约定这条路留给协调节点加人的确认。
六、把它当架构参考，四件事得自己补
发布方说得明白：这是原型而非正式产品，部分设计尚未实现，实验基于合成负载与简化环境；配套研究原型也以宽松许可开源出来供人取用。这两句声明在评审会上不该被当成缺陷来念，也不该被当成客套略过，它们的正确用法是划定可借用的范围：架构分层、职责切分、事件驱动这套方向性结论可以借；量级结论不能搬，生产负载里失败率与长尾的分布，简化环境不会替我们呈现。
在洹拓评估这类改造时，接入前必须自己补齐的是四件事，一件都不能少。
- 失败恢复与断点：任务跑到一半执行体停了，谁负责判定它已经终止、已产出的东西是否可复用、重来一次会不会造成对外部系统的重复写入。
- 并发上限与队列：多个执行体同时展开时，模型调用额度、仓库侧的并发限制、评审与合并队列的吞吐，哪一项先成为上限；超限时是任务排队还是拒绝新触发。
- 成本熔断：协调层决策次数与缓存读取量涨到什么程度要自动停止派发；熔断以后靠什么留证，让人能看清当时停在哪一步。
- 结果验收判据：执行体报回来的结果由谁、按什么条件判为可提交。如果验收还是得人在多个会话之间来回看，那这台机器省下的注意力就又还回去了。
这四件事补齐之前，它只是一份可以照着讨论的图纸。本篇也不把它写成任何采购建议：既不等于我们已经这么跑，也不等于该按这套结构给客户交付项目。能确定的是那两本账的口径——先分列，再谈要不要花这笔协调成本。