最近GPT-6发布以后讨论最凶的一句话是“能干活也看得住”。跑分刷得再热闹真正用过的人都清楚单次对话跑一个几百行的任务不算本事难的是让它稳定扛住一个完整项目、不跑偏、不翻车。我认识的老K用了个非常激进的方式试了一次——让GPT-6管GPT-6。他拿一个总控智能体去调度一批同样基于GPT-6的执行智能体用一周时间搭出一个被他称为“曼哈顿”的系统覆盖需求拆解、资料研究、方案生成、代码落地和质检修正五条流水线十个Agent节点同时跑。整套东西在第七天稳定交付中间踩的坑、调的参数、试出来的经验我觉得很值得拆开聊聊。1. 先搞明白问题为什么要让AI管理AI1.1 “曼哈顿”到底是什么项目老K当时接到的活儿是做一个垂直领域的自动调研与内容生产系统。简单说用户给一个行业问题系统要自动完成资料检索、结构化分析、方案撰写和报告生成最好还能把里面涉及的可执行模块直接产出代码。传统做法是写一堆接口、串一堆Prompt、再人工校对但问题也很明显这是一个长链条任务单靠一个会话根本扛不住。他把这个项目的代号定为“曼哈顿”倒不是要复刻纽约而是因为整个系统节点密、并行多、时间紧——十个Agent节点同时开工任务像曼哈顿街区的行人一样密集交错。老K的要求很直接一周内跑通一个可演示、能真实交付的MVP不是玩具Demo是要能在行业客户面前现场跑出结果的那种。说实话我一开始觉得一周太紧。但老K坚持把“让AI管理AI”作为核心架构理由也很朴素与其让一个人盯十个线程不如让一个模型的总控角色去盯九个干活角色。人只负责最终拍板和最关键的质检。1.2 单会话的“天花板”为什么逼人换思路很多人习惯把复杂任务塞进一个超长Prompt里指望GPT-6在一次对话里全部搞定。但实际用下来单会话有两个天然瓶颈。第一个是上下文窗口再大也有限。一个真实项目会有需求描述、历史决策、中间产物、外部资料这些东西全部塞进去很快就逼到窗口上限。更麻烦的是模型处理长文本时会出现“远端遗忘”开头强调的约束到后面可能就丢了。第二个是“线性对话”没办法真正并行。A模块的资料研究、B模块的代码生成、C模块的质检本来可以同时推进但在单会话里只能串行执行。老K算了一笔账五个工作流串行跑每个工作流需要六到八轮交互一轮交互要等模型完整输出一整套跑下来光等待时间就超过一天。所以“让GPT-6管GPT-6”本质上不是炫技而是把大模型从“单兵作战”变成“团队协作”。总控Agent负责拆任务、派活、验收执行Agent只干自己那一亩三分地。类比一下一个人再厉害也没办法一星期拍出十集电视剧但给他一个导演组、编剧组、剪辑组配上总监盯着进度这事就可能做成。1.3 评测标准既要“能干活”也要“看得住”“能干活也看得住”这个热搜词放在真实项目里其实是两个可以量化的指标。“能干活”指的是任务完成质量和交付率也就是每个Agent能不能把自己负责的模块做出来“看得住”指的是过程受控程度包括有没有跑偏、有没有把错误结论当成事实往下传、有没有产出与需求无关的东西。老K给这套系统定了三个核心指标任务完成率、返工率、跑偏次数。任务完成率衡量每个Agent按时交付的比例返工率看一次通过率和需要打回重做的比例跑偏次数则是总控在验收时发现“结果与需求不一致”的频次。这里就必须提一下跑分问题。老K的看法很直接所谓跑分看看就好。公开评测集很可能被部分训练数据覆盖跑分高不代表真实场景好用。所以他要求团队临时搭建了一套私有测试样本从真实行业问题里抽了二十个典型需求人工标注了标准产出专门用来做验收。聊到OpenAI那个“跑分作弊”的争议老K的原话是“与其纠结分数怎么做出来的不如自己准备一套题。”2. 系统整体架构四层智能体如何协作2.1 总控层Supervisor Agent的定位与指令整条流水线的核心是总控层。老K管这个角色叫Supervisor Agent它就像一个项目总监不负责具体写代码、不负责调研只负责三件事拆解任务、分配资源、验收结果。总控的系统指令我看了初版核心逻辑很清晰输入是所有任务的目标和背景说明输出是一个结构化的任务调度命令。比如一条行业需求进来之后它先判断这个需求能不能拆解成“资料调研、方案撰写、代码实现”三个子任务然后分别派给对应的Worker Agent并约定产出格式和截止时间。关键在于总控本身也是GPT-6它同样可能“想当然”。所以老K给它的指令里加了一条硬约束所有决策必须输出JSON包含task_id、执行者、优先级、期望产出、验收标准。这样做的好处是即便总控判断失误下一层的Agent也能基于结构化信息发现问题不至于让错误在模糊的自然语言里蔓延。2.2 执行层五个工种的Worker怎么配执行层一共五个工种分别是资料研究员、方案架构师、代码工程师、文档工程师和数据分析师。每个Worker都是一个独立配置的Agent实例底层模型都是GPT-6 Astra但系统指令完全不同。资料研究员的指令里强调了“只允许基于检索到的资料做归纳不允许用记忆补充未验证的数据”代码工程师的指令里写了“输出必须包含可运行代码和依赖清单不做无法验证的承诺”文档工程师则被要求“用结构化Markdown输出禁止空话”。这里有一个很容易被忽略的细节每个Worker都是独立的会话上下文互不相通。执行A任务时产生的中间状态不会自动传给执行B任务的Agent。老K说这是故意设计的目的就是防止一个Agent的错误判断污染整条流水线。Worker之间要传递信息必须通过总控中转总控成了唯一的信息枢纽。2.3 评价层质检Agent拥有“否决权”执行层做完任务直接交付给质检Agent这一步是曼哈顿系统里我最认可的设计。质检Agent不写代码不生成内容它对每个交付物做结构化打分维度包括完整性、可用性、一致性、格式规范并输出一个错误类型枚举比如“信息缺失”“逻辑断裂”“格式不符”。为什么质检要单独一个Agent因为“让生产者自己检查自己”在AI场景里也很难成立。代码工程师觉得自己写完了方案架构师觉得自己没问题如果只靠总控审核总控的上下文里塞满了大量细节很容易漏检。质检Agent独立出来之后它只认标准和规则有一种“拿着尺子量”的感觉。而且质检Agent拥有否决权评分低于阈值的交付物直接打回给原执行者附上原因编号。老K说这是模仿真实团队里的Code Review机制——生产者和审核者分离质量才有保障。2.4 人在环路关键节点保留人工审批有些人一听到“让AI管AI”就会想象成完全无人化。老K的曼哈顿系统显然不是这样在四个关键节点必须人工确认需求接受阶段、方案选型阶段、高风险依赖引入阶段、最终交付阶段。举例来说需求拆解后总控会生成一份任务分解清单项目经理需要确认这个拆法是否合理方案架构师选了一个外部数据源接口如果总控判断该外部依赖风险较高就会升级给人做审批。这样设计的目的是让人把精力集中在“决策”上而不是消耗在“盯过程”上。这是我最想强调的一点AI管AI强调的是过程自动化和决策辅助不是把人的判断力完全拿掉。尤其是面对行业客户时人工审批节点反而是展示专业性的窗口。3. 一周搭建实操记录从零到曼哈顿的关键动作3.1 第一天先把任务状态机定下来老K没有一上来就写Prompt第一天的全部精力用在了定义任务状态机上。整个系统的所有Agent共用一套状态流转逻辑待处理任务已经创建还没有分配执行者执行中任务已经派给某个Worker正在处理验收中Worker提交了产出质检Agent正在审核已通过质检通过等待汇总需返工质检未通过附错误编号打回已关闭任务完成可以归档每个任务实例都带一个JSON元数据结构包含task_id、状态、负责人、优先级、输入摘要、输出产物、验收结果、返工次数。第一天结束的时候这套状态机已经在代码层面跑通了。老K说状态机是整个系统的骨架Prompt只是血肉。3.2 第二天总控系统指令的编写要点第二天写总控Agent的系统指令老K给我看了两版第一版太“自由”第二版才真正可用。第二版的核心结构我抄了一个精简版你是曼哈顿系统的总控Agent负责任务拆解、执行者调度和结果验收。 工作原则 1. 收到任务后先判断是否可以拆解为多个子任务。 2. 每个子任务必须明确执行者、输入、期望产出、验收标准。 3. 所有决策以JSON输出格式如下 {action:dispatch,task_id:xxx,executor:researcher,input:xxx,expected_output:xxx,acceptance_criteria:xxx} 4. 收到执行者的产出后调用质检Agent验证。 5. 如果质检未通过记录错误编号并将任务退回原执行者。 6. 同一个任务返工次数不得超过3次超过3次必须升级给人处理。这个指令里最重要的一句话是“所有决策以JSON输出”。它能逼着总控把模糊判断变成结构化动作后续联调排错会省很多事。3.3 第三、四天执行Agent的上下文隔离与配置第三、四天的工作重点是把五个Worker的配置逐个打磨。每个Worker的文件里包含角色描述、任务范围、输入格式、输出模板、禁止行为、质量自检清单六个部分。以代码工程师Agent为例你是曼哈顿系统的代码工程师负责根据方案文档编写代码。 任务范围 - 只处理方案文档中标注为“待实现”的模块 - 不负责需求变更判断 输出模板 - 代码块 - 依赖清单 - 运行说明 - 已知限制 禁止行为 - 不输出未经测试的伪代码 - 不使用未在依赖清单中出现的第三方库 - 不擅自修改输入需求 质量自检清单 - 代码是否能直接运行 - 是否处理了边界输入 - 是否输出运行说明这轮配置真正解决了一个常见问题单个Agent跑起来容易“自由发挥”给客户演示的时候经常突然编出一个需求里根本不存在的功能。要么是上下文里有类似信息被错误关联要么是模型过度联想。加了“任务范围”和“禁止行为”约束之后这个问题明显缓解。上下文隔离方面每个Worker独立开一个会话总控在和Worker交互时只发送精简后的任务卡不把全量历史记录带过去。这个设计对控制Token消耗非常关键。3.4 第五到七天联调、压测和人工抽检第五天开始联调。第一批测试跑了五个需求样本跑完之后暴露了一个共性问题质检Agent太严厉几乎每个任务都要打回一次。原因在于验收标准写得太抽象比如“内容完整性”没有量化标准质检Agent只能靠感觉判断。于是老K调整了质检Agent的评分规则把“完整性”拆成“是否有遗漏需求项”“是否有未回答的子问题”“是否缺少数据支撑”三个可核验的条目。调整后返工率从接近八成降到三成左右。第六、七天是压测和抽检。压测主要看两件事任务并发处理能力以及长时间运行后的稳定性。老K跑了十个任务的全流程追踪每个任务的完成时间和返工链路记录哪些环节出现了等待超时或Token超限。人工抽检则是对最终产出做抽样从一开始每个任务都看变成按批次抽检抽检比例约三成全部通过后系统才正式交付。4. 成本拆解与控制GPT-6很贵钱要花在刀刃上4.1 一周的真实Token账单长什么样GPT-6的价格不便宜曼哈顿系统又是一个跑满全流程的重度使用场景。老K拉了一周的账单大头消耗分三块总控Agent的调度与验收消耗约占25%执行Agent的内容生产消耗约占55%质检Agent的评分与复核消耗约占20%最出乎意料的是质检Agent的消耗。一开始我以为质检只做简单打分不该花太多Token而实际上如果要求它输出详细错误类型它需要重新阅读交付内容并比对验收标准相当于把任务又跑了一遍。4.2 三条省钱实操缓存、批量、小模型前置过滤老K总结了三套控制成本的手段现在已经被他用到其他项目里了。第一缓存高频任务。系统里很多任务存在相似输入比如“请解释某某指标的计算口径”这类问题答案相对稳定。老K给总控加了一个Redis缓存层一模一样的任务卡直接返回历史最优结果不再调用GPT-6。第二能批量合并的任务一起跑。有些任务拆出来粒度很细比如同一篇文档里的多段内容润色逐段启动Agent会浪费大量上下文切换成本。老K把这类任务合并成一个批次用一次会话处理多个子任务再按输出模板拆开。第三用小模型做前置过滤。不是每个输入都值得进入全流程。老K在入口加了一个轻量级分类器基于更小、更便宜的模型做意图识别如果判断这个需求属于“简单问答”直接走模板回复不进入整套智能体流水线。前置过滤挡掉了大约四成的无效请求省下的成本相当可观。5. 常见问题与排查技巧实录5.1 上下文污染一个Agent的旧结论污染整条线曼哈顿联调第二天就出过一件怪事资料研究员Agent生成一份报告里面居然出现了“本报告基于上一轮数据修订”这类话。排查后发现总控在给Worker发任务卡时不小心附带了一段历史汇总文本里面有关于上一轮任务的描述。Agent读到这段内容后错误地把它当成了当前任务的背景。排查思路很简单把所有传给Worker的任务卡全部打印出来人工比对看是否携带了额外信息。修复方式是在总控的转发逻辑里加了白名单字段只允许指定的输入字段进入任务卡其他一律过滤。5.2 幻觉在反馈回路中被放大比单次幻觉更麻烦的是幻觉会在反馈回路里被放大。第一次测试时方案架构师基于一份检索结果写了一个“当前市场渗透率约30%”的数据。质检Agent在复核时没有发现数据来源可疑于是放行。后面的分析师Agent又基于这个数据做了进一步推算错误就这么传了三层。这个问题的根源在于质检Agent只会做“逻辑核对”不会做“事实溯源”。老K的解法是给质检Agent增加了一条规则凡是报告里出现具体数字必须标注数据来源如果来源缺失直接判定为“信息缺失”并打回。这条规则加完之后虚假数字跨层传播的情况大幅减少。5.3 总控拖慢整条流水线总控是单一中枢好处是信息集中坏处是容易成为瓶颈。压测时发现当十个任务同时跑总控需要排队处理各类请求单条任务链的总耗时被明显拉长。老K分了两个层次处理。首先简单任务不进总控Worker之间可以通过预定义的轻量事件总线传递信息只有跨工种协作或者需要验收的情况才走总控。其次给总控设置“超时默认放行”机制如果某个Worker超过预设时间没有响应总控先按默认规则继续流程之后再做补偿性修正。5.4 Token预算告警与兜底方案最后一个常见问题是预算失控尤其是执行Agent生成超长输出时一次调用可能烧掉大量Token。老K在每个Worker的配置里加了max_tokens硬顶超过上限自动截断并提交给质检同时设置全局限额单日消耗超过预设值后系统自动降低任务并发量。做一个速查表方便遇到类似问题的人快速定位症状可能原因处理方式结果出现不相关内容上下文污染检查任务卡字段增加白名单过滤数字或事实被跨层传播质检缺少溯源规则强制要求数据标注来源任务链路耗时过长总控成为瓶颈增加事件总线分流转发Token消耗异常高单次输出过长或无效任务过多设置max_tokens增加前置过滤6. 复盘与后续扩展6.1 什么项目适合这种“AI管AI”方式老K的曼哈顿系统跑通之后我一直在想一个问题是不是所有项目都适合让AI管AI答案显然是否定的。适合这种方式的项目有很明显的特征目标可以被拆解成多个相对独立的任务、每个任务需要不同类型的处理能力、任务之间的交接有标准化产物、效果能够用明确规则验收。反过来如果项目本身高度依赖直觉和审美比如需要大量原创性创意设计或者任务之间存在难以言说的隐性依赖那这套架构目前还很难替代人的全局把握。总控Agent再强大它也需要先能“说清楚”验收标准才能做有效的管理和返工。6.2 从曼哈顿到常态化的三个改造点再往后走老K计划从三个方向做改造。第一个是让总控Agent具备更强的“主动性”不再完全是被动处理任务而是能根据项目目标和进度主动向人提问、反馈风险预警。第二个是让质检Agent具备跨任务的一致性好坏判断比如整个项目里所有报告的语气、格式、深度是否一致这种全局审美目前还需要人来把握。第三个是在任务级加入更多人工反馈信号每次人工审批时打上标签持续用来微调总控的拆解策略和质检的判定逻辑。另外这套系统里的代码产出还会逐渐接入自动测试工具代码Agent写完代码后直接跑单元测试测试结果再回流给质检减少人工介入成本。整体上它越来越像一个真正有组织结构的数字团队而不是一堆孤立Agent的简单堆叠。6.3 关于“AI管AI”我自己的真实体会如果把这件事最核心的经验压缩成一句话我会说是让AI管AI的关键不是模型能力本身而是你有没有把“管理规则”定清楚。总控Agent的任务拆解、质检Agent的评分标准、Worker之间的信息隔离、人工干预的关键节点这些才是真正决定系统能否落地的因素。模型负责的是理解和生成规则负责的是秩序和质量。如果有朋友也想做类似的实践我的建议是先小规模跑通一个三节点的链路比如“资料调研—方案生成—质检返工”把状态机、JSON输出、返工逻辑都理顺了再往上面加节点。别一上来就十个Agent同时跑那样出现问题你根本不知道是哪个环节出了问题。先让它管住三个再让它管住十个这才是稳妥的路子。最后再分享一个技巧永远不要相信不经过返工一次就交付的Agent。第一次就能完美交付的任务要么太简单要么质检标准太松。给每个任务留一次合理的返工空间跑出来的结果会比一次通过的稳定很多这是我在曼哈顿项目里反复验证的一条经验。