本文来自微信公众号： DARE to B2B ，作者：申飞 Dare，原文标题：《从选模型到派任务，我的多 Agent 工作流走到哪一步》
头条《当Agent能同时干活，谁来守住人的注意力》谈的是DeepSeek的Super-agent设计：任务多起来以后，系统需要接住分派与交接，把验收节点清楚地留给人。读到这里，我先想到自己每天在几个AI窗口之间来回切换的麻烦。
一篇稿子要查资料、改文字、做图，可能由不同工具接力。换个窗口继续做，就要重新说一遍：哪份是当前稿，哪些判断查过来源，排完版能不能发。即使只用两款AI，这种交接也不会自动发生。写稿的一部分动作交给了工具，补背景、核对状态仍要人来做。
我的工作还经常在内容、代码和资料整理之间切换，macOS上同时用Cursor、Codex、DSH和Claude Code。用得越多，越能看清这是两件不同的事：一次请求该发给哪个模型？一项任务该交给哪个Agent负责、做完由谁验收？我先搭了前一层，后来才开始给后一层立规矩——选对模型只管单次调用去哪，管住派活和交接，人才能从窗口切换里抽身。
处理第一个问题时，我把本机接入拆成了两个端口服务：8081是决策与能力网关，8082是模型聚合出口。请求先按入口别名划定出站许可——hybrid-auto是严格本地的API别名，hybrid-auto-cloud才允许把云端列为候选（因此DSH Web的智能入口只是自动选路，不能被误认为私密模式）。向量检索、网页搜索等能力也从8081统一入口提供。这一层解决的是一次请求去哪里、能调用什么。
如图一所示，请求进入8081后，先检查真实输入和能力要求：规则能直接决定的直接选路；需要语义判断时，先问本地的轻量决策模型JEV。本地JEV低置信度就回退规则，不因此把正文送往云端；只有获得出站许可且本地决策不可用，才考虑云端JEV兜底。执行模型另行选择，向量检索和网页搜索则是独立能力端点；8082只承担模型聚合转发，不负责决定谁接一项工作。这套智能路由目前还在试运行，真实会话与分层样本的完整验收尚未做完，还不能称为全面接管所有客户端的成熟系统。
模型选对了，开头那件交接的麻烦还在。网关可以分流一次调用，却不会天然知道一项工作走到哪一步，更不知道“写完”是否等于“可以发布”。跨bot、跨工作区时，任务状态和授权必须另有去处。
所以最近我的重心开始移向任务层。我给负责总编排的feibot写了一份私有分派规则：由它接需求、把住授权，再按工作领域交给现有的专业bot，不再另设一个总控。能交给执行端的活，它不自己长时间处理；分派后先告诉我“已交给谁”，等执行端回报终态，再把结论收口转给我。
这份规则也把成本放进了分派条件：前期摸排线索优先用免费资源，具体工作尽量交给已付费的执行引擎，feibot留在拍板和收口的位置。执行端的终态回报要说清四件事——结论、验证办法、所用引擎与停止原因；大结果留在文件里，聊天窗口只传摘要。跨会话交接则靠工作区的任务卡和精简交接记录，把目标、已确认状态、文件位置和剩余审批记在明处，外发、发布和生产改动仍要单独核对授权。
把图一和图二放在一起，两层的边界就清楚了：智能路由分配模型请求，任务编排分配责任。前者问“这次用本地还是云端、需要什么能力”；后者问“谁接活、依据什么授权、结果落在哪里、谁验收”。它们可以连接，却不能用一个API网关替代另一层的状态管理。
按这套做法，我确实已经开始跨Agent、跨bot、跨工作区派活，但更准确的说法是：分派规则与交接方式已建立，端到端自动化仍在形成。本机网关有代码，feibot的私有分派规则有明确的领域表、成本选择和终态回报要求，工作区也有任务卡；不过图二画的仍是分派规则规定的工作路径，不是跨bot自动化已完成的运行截图。现有材料证明了“怎么派”的设计与约束，还不能证明多个bot已能在不同工作区之间持续、自动、可靠地走完任务，也没有可用的效率对照数据。
回到头条提出的注意力问题，下一步要靠真实任务记录来回答：选同一类日常任务，把从入口接收、授权判断、分派、执行、交接到验收的每一步记下来，保留失败与人工接管的次数，再看一次任务究竟少了多少人工转述。若每次跨工具都要我重新解释背景，派活只是换了说法；只有任务状态和权限能随工作一起走，关键判断在该由我决定时回到我手里，跨Agent协同才算真正开始减轻人的负担。