用 1000 倍 Token，换 10 倍有效产出
与其再造一个编码 Agent，不如构建一个管理层，让现成执行器持续协作，以更多推理计算换回经过验证的交付和人的时间。
Multi-Agent 的产品哲学与主动型助手
与其再造一个编码 Agent，不如构建一个管理层，让 Claude Code、Codex 等现成执行器持续协作，完成一个人难以同时推进的工作。
这套产品思路押注于模型能力提升、推理速度加快和单位成本下降。但即使模型能力暂时不变，也有一个值得探索的问题：
投入 10 倍、100 倍乃至 1000 倍的推理计算，能否换来 10 倍以上的有效产出？
这里的产出，不是更多代码、更多对话或更多运行时长，而是经过验证、可以交付的工作。允许大量尝试失败，允许多条路线被淘汰，但最终必须减少人的介入，或者显著提高完成工作的速度和数量。
一、Multi-Agent 的产品哲学
1. 优先选择难求解、易验证的问题
适合大量投入计算的问题，最好具备三个特点：定义清楚，搜索空间大，验证成本明显低于求解成本。
定义清楚，意味着目标、约束、输入输出和验收条件可以明确描述。搜索空间大，意味着存在大量候选方案，值得并行探索。容易验证，意味着方案是否有效，可以通过测试、编译、形式化检查或仿真判断，而不是主要依赖主观评价。
具有明确规格的编译器、解释器、算法、数学证明、电路仿真和部分 CAD 任务，都可以沿着这个方向寻找切入口。
相反，“做一个好用的社交产品”“设计一座令人满意的建筑”“运营好一家公司”，本身都不是封闭任务。它们需要持续观察现实、补充约束、调整目标，不能因为增加了 Agent 数量，就自动变成能够客观求解的问题。
长期目标可以复杂、开放，但分配给执行 Agent 的每一步，应尽量明确、封闭、可以验收。
2. 用软件工程组织工作，而不是模拟一家公司
Multi-Agent 不需要先配齐 CEO、产品经理、架构师、程序员和测试，再让这些角色反复开会。
角色名称不能解决任务边界不清的问题。把一个模糊任务分给二十个角色，通常只是把一次不确定的执行，变成二十次相互依赖的不确定执行。
需要继承的是软件工程的约束，而不是公司的组织形式：
明确规格 → 完成设计 → 划分模块 → 约定接口 → 分配实现 → 独立验收。
每个 Agent 应尽量拥有独立的任务、上下文和执行环境，减少共享状态和无关沟通。任务之间传递必要的输入、结果和验证证据，而不是完整复制彼此的思考过程。
跨任务依赖可以组织成 DAG，也就是有向无环图：哪些工作可以并行，哪些工作必须等待前置结果，应当清楚。单个任务内部则可以循环尝试、验证和修复。依赖关系保持清楚，不意味着执行过程不能反复迭代。
代码在这里是可替换的实现，规格、接口约定和测试才是需要持续维护的资产。需求变化应先反映到规格中，再决定修改还是重写相关模块。重写是一种实现策略，不是自动消除复杂性的保证。
3. 不接受完成声明，只接受验证证据
一个 Agent 说“完成了”，不能成为另一个 Agent 接手的充分条件。管理 Agent 再说一遍“我确认完成了”，也不等于验证。
未经验证的产出，应视为待检查的候选结果。接收方需要确认：实现是否符合规格，测试是否能够复现，结果是否适用于当前版本，组合后是否破坏其他功能。
验证可以包括独立编写的测试、实际编译运行、回归检查、仿真结果或形式化证明。不能让执行者通过修改验收标准，把自己的结果变成“正确”。
大量测试的价值在于覆盖约束和发现错误，而不是数量本身。模块分别通过测试，不代表集成后一定正确；通过既有检查，也不代表超出检查范围的性质已经得到保证。
因此，验收至少需要区分三种状态：通过、未通过、无法判定。
发现明确反例，是未通过；检查工具报错、环境不可用或证据缺失，是无法判定。把这两者混在一起，管理层就可能错误淘汰有效路线，或者接受没有被真正检查过的结果。
Multi-Agent 的协作基础不是相互信任，而是结果可以被独立检查，错误可以被定位，结论可以被追溯。
4. 围绕目标持续推进，而不是围绕会话结束工作
长期任务不能依赖某一个 Agent 一次性发挥稳定。
执行 Agent 可以失败、卡住、耗尽上下文，也可以在一次会话结束时报告当前进度。但这些不应该自动意味着整个目标结束。
管理层需要保留目标、当前状态、已验证结果、失败记录和下一步动作。某条路线失败后，可以修复环境、补充测试、调整方案、启动另一条路线，或者替换执行 Agent。
停止条件应由用户配置，包括成功标准、预算边界、暂停条件和需要人工决策的事项。执行者不能自行降低目标，把未完成包装成完成；管理层也不能把持续运行等同于持续进展。
可以让系统工作一百小时，但必须知道它这一百小时排除了什么、验证了什么、还缺什么。
二、主动型 Agent：让管理层长期参与工作
1. 不重造执行器，而是构建管理层
产品的核心不是从头实现一个更会写代码的 Agent，而是构建一个 Agent management：它可以是工具、策略，也可以是一层长期运行的系统，内部调用 Claude Code、Codex 或其他执行器。
管理者本身也可以由 Agent 担任，负责创建子任务、启动子 Agent、检查进展和组织验收。不必把每一步流程都手工写死，但无论由程序还是 Agent 编排，都需要遵守相同的权限、状态和验证规则。
执行器应当可以替换。Skills、结构化记忆、计划机制、目标管理和调度策略，应当可以独立配置、按需组合，而不是全部固化在一个不可拆分的 Agent 内部。
这样的系统不只是开发工具，也可以成为产品的运行层。用户消费的不只是它提前写好的代码，还包括它在运行过程中持续完成的分析、决策和操作。
2. 把桌面活动转化为任务上下文
传统交互通常从用户发出指令开始。主动型助手则需要在授权范围内持续观察工作状态，识别什么时候有值得推进的事情。
它可以把桌面信息提取为元数据：正在使用什么应用，处理哪些文件，属于哪个项目，最近完成了什么，当前卡在哪里。再用时间线组织这些信息，将零散操作还原为连续任务。
整个过程可以概括为：
桌面观察 → 提取任务信息 → 更新工作时间线 → 识别下一步 → 请求授权或按既定权限执行 → 返回验证结果。
例如，用户在电路设计软件和仿真工具之间切换，系统发现某个版本已经修改，但对应仿真尚未完成，就可以提出：
电路版本已更新，但还没有对应的仿真结果。是否运行既定检查，并汇总异常？
主动不意味着持续弹窗。已经授权、风险较低的例行工作可以直接执行；需要新增权限、产生外部承诺或进行高影响修改时，再请求确认。
目标不是增加一个不断打断人的助手，而是减少用户重复补充上下文、催进度和交代下一步的次数。
3. 持续工作几天或几周，而不是维持一条超长聊天
长期任务的进度不能只存在于聊天记录中。
系统需要明确记录任务目标、文件版本、执行状态、依赖关系、验证证据和待处理问题。某个执行器退出、上下文被压缩或运行环境重启后，工作仍应能够恢复，而不是要求用户重新解释一遍。
管理层负责持续调度：哪些工作可以并行，哪些需要等待，哪些值得增加计算，哪些已经没有进展，哪些必须交给用户决策。
Computer use 则让执行范围延伸到桌面软件。任务可以跨越 IDE、设计工具、仿真环境和文件系统，而不局限于一个代码仓库。
实现上，可以从本地桌面应用开始，用 TypeScript 搭建管理逻辑，用 Electron 承载交互界面和快捷键入口，再逐步连接执行器与桌面工具。界面只是入口，真正需要建立的是持续的任务状态和可靠的执行闭环。
三、具体场景：管理复杂目标，执行明确任务
1. 同时推进多个外包项目
假设一个人同时承接四十项外包工作，问题不只是“让四十个 Agent 分别写代码”。
这些任务有不同的截止时间、需求完整度、验收标准和资源需求。有些可以立即执行，有些需要客户确认，有些已经完成实现但缺少验证，还有些正在等待前置任务。
管理层需要维护整个任务队列，把计算分配给当前最值得推进的工作：需求明确的进入执行，结果不稳定的增加验证，依赖未满足的暂时等待，需要外部决策的集中交给用户。
用户不必逐个盯住执行者，而是掌握少量真正需要自己决定的事项，以及已经通过验收的交付物。
这里的效率提升，来自并行执行与管理负担的同时下降，而不只是启动更多进程。
2. 长程电路设计与建筑设计
复杂电路可能涉及原理图、元件选型、软件接口、硬件协同、仿真和多轮修改。大型建筑设计也可能涉及大量模型、图纸、参数和相互依赖的约束。
这些工作适合作为长期管理的目标，但不能仅凭一句“把它设计出来”，就成为可以自动验收的任务。
系统需要把整体目标拆成明确的工作单元：补全一个模块、运行一组仿真、检查一类约束、比较几种方案、整理一批待决问题。每一步都应有对应的输入、输出和检查方式。
管理层维护全局目标与依赖，执行 Agent 在各自工具中推进局部工作，再将经过验证的结果合并。涉及现实安全、专业判断或未定义需求的部分，仍需要相应的人工审查。
长期自主执行的基础，不是一次理解所有复杂性，而是持续把复杂目标转化为可执行、可检查的下一步。
3. 并行游戏建模与素材生产
游戏建模、素材生成和关卡测试，可以用来探索更高并行度的工作方式。
例如，为二十个执行者准备隔离的容器或虚拟机环境，分别处理不同模型、素材或候选方案。任务开始前，约定风格、尺寸、命名、文件格式、资源预算和导入要求。
每个执行者先完成本地检查，再提交结果。管理层负责比较候选、拒绝不合格产出，并检查合并后的场景是否满足整体要求。工具与硬件允许多少并发，应由实际资源条件决定。
并行产生更多候选，不等于并行产生更多可用资产。收益取决于任务是否足够独立、验收是否清楚，以及最终筛选和集成是否仍需要大量人工。
四、允许多花计算，但必须换回人的时间
如果默认每一次额外调用都是浪费，就很难探索高计算投入的产品形态。
同一个任务可以尝试多条路线，同一个结果可以接受独立检查，同一个失败可以被反复定位和修复。系统可以在用户休息时继续运行，也可以为少量高价值任务投入远超日常问答的资源。
允许浪费候选方案，不意味着允许交付未经验证的结果；允许增加计算，不意味着允许增加人的管理负担。
即使把每天消耗上百亿 Token 作为极端设想，真正要回答的仍然是：这些计算完成了多少有效工作，减少了多少人工介入，是否值得它消耗的资源。
“1000 倍 Token 换 10 倍提升”应当是一个需要验证的产品目标。比较时，要固定任务范围和验收标准，再分别测量交付时间、人工介入时间、通过验收的工作量与总成本，不能用生成量代替效率。
这也决定了 Personal Agent 与 Business-Level Agent 需要不同的资源供给方式。免费问答、临时杂务，与长期运行的多智能体、完整执行环境和持续仿真，不是同一种成本结构。资源密集型服务需要对应的付费机制，或者由用户自行搭建并承担成本。
“个人使用”不等于计算需求轻量，“商业服务”也不只是多一个付费按钮。产品必须明确提供多少资源、允许多少并发、如何停止，以及由谁承担费用。
最终，要做的不是一个会制造更多工作的系统，而是一个能够接住工作的系统：理解目标、组织执行、验证结果，在需要人决策时提出明确问题，在不需要人介入时持续推进。
Multi-Agent 的价值，不在于有多少个 Agent 同时忙碌，而在于用户少介入之后，仍然有多少工作能够可靠完成。