给智能体系统加可靠性，最常见的动作是往调度层里塞更多上下文和规范，让它“想得更周全”。Meta 在 10 月 19 日的工程博客里说，他们试过，然后放弃了；最后让系统变可靠的改动，是把调度层里的推理拿走。
一个装了全部知识的智能体，在生产里垮了
事情发生在 Meta 内部的数据管道上。接入一个新数据列，要跨三个代码仓库、三种编程语言、最多六个流水线阶段做协同改动。第一版方案是一个装载全部知识的智能体：三个仓库的完整模式定义、Python 与 C++ 和 SQL 各自的语法规则、阶段之间的依赖顺序、每个阶段的校验规则、出错后的恢复流程，全在它一个上下文里。
演示跑得通，上了生产开始生成无效配置。Meta 事后给的归因不是知识不够，是知识太多：超过某个上下文阈值之后，追加的知识反而拉低表现，智能体会把一个子系统的字段命名规则套到另一个子系统上，或者拿针对某个数据源写的代码生成模式去填另一个数据源。他们的形容是，一个智能体淹在自己的知识里。
中间还试过一条更常见的路：给每个具体任务手写系统提示。这样成功率能到 70% 至 80%，不这么扶着就掉到 10% 至 20%。Meta 的判断是这不属于提示工程问题，属于架构问题。
七步里只有一步让模型思考
重构后的形态是这样的：一个约 1300 行的编排器，把 20 多个工作流路由给 14 个专项智能体，自己不做任何领域工作。
前五步和第七步是确定性的，只有第六步涉及大模型推理，而且发生在只加载了自己领域知识的隔离子智能体内部。专项智能体结构统一，各自带运行时要加载的领域知识文件、委派前必须收齐的字段、分步执行计划、找代码模式的方式和故障到修复办法的映射。25 个以上按领域组织的知识文件按需加载，改完下次会话就生效，编排器不用动。
扩容方式也跟着变了：需要支持管道迁移这个全新用例时，Meta 没有造新智能体，只写了一份把既有智能体换顺序的工作流模板，新增智能体代码为零。第 15 个子智能体和第 1 个在结构上长得一样，加一个是模板活，不是从零开发。
可靠性不是靠加上下文，是靠划边界
真正值得带走的是它背后的判据，而不是 14 这个数字。Meta 给的五条原则里，第一条和第五条是同一件事的两面：把路由和推理分开；对每个组件都明确问一句，这是路由决定（确定性）还是推理任务（概率性），编排器在一边，子智能体在另一边，不要混。
胖编排器的失败模式被写得很具体：它一旦产生幻觉，错误会扩散到下游全部环节——路由到错的智能体、收集错的字段、或者跳过可靠性检查。瘦编排器留给幻觉的空间很小，因为路由和可靠性检查不依赖大模型推理，它走的是固定协议。创造性发生在下游那些隔离的、领域限定的上下文里，那里幻觉风险被最小化，失败也被关在里面。
还有一处容易被读过头的数字。若干转载站点写“幻觉率从 12% 降到 2%”“成功率从 78% 升到 94%”，这些在 Meta 官方原文里查不到。官方给出的是：约三分之二的变更无需重大人工编辑即可落地，新数据列的配置准备从手工三四天压到不到一小时，以及一句限定——幻觉风险是被最小化，不是被消除。
另一半答案：稀缺的不是提示词，是评分标准
同一天 LangChain 博客发的英国数字健康公司 Numan 的复盘，落在同一件事的另一半上。
Numan 的产品 Nu 是一个 AI 健康教练，边界很硬：按英国 MHRA 的指引，一个给出临床建议、做诊断或推荐治疗的软件就构成医疗器械，Nu 被设计成只做生活方式教练与健康教育。他们一开始做的评测是标准打法——一批输入输出对，配一个大模型裁判打分。然后发现两条路都走不通。
单轮静态样本不行，因为教练是一场对话而不是一个回答，有没有答好取决于上下文；更要紧的是，全样本取一个平均分会把失败藏起来，几条坏回复几乎拉不动那个数字。他们碰到过一次低分聚集，查下来是评测标准自己的问题：评分标准要求在两轮之内同时完成共情、探询和建议，而真人教练会把这三件事铺在整场对话里。脚本化多轮对话也不行，因为患者的第二句话是预先写好的，一旦 Nu 第一句说了脚本没预料到的话，后面每一轮都在回一场没发生过的对话。
他们现在跑的是三层。能用单条回复判定的（路由对不对、用药问题答得安不安全、安全护栏该拦的拦没拦），走按类别打分的主题数据集，每类单独出分，某一类扎堆失败就藏不住；评分标准只问一条回复能体现的东西，不再因为教练式铺陈而扣分。必须由整场对话形状来判的，走模拟对话层：给评测一个人设、一个场景、要探出的关键问题和轮次上限，让一个更便宜的模型扮演患者跟真智能体多轮对话，再由裁判按类别给整份记录打分。因为患者是生成出来的，可以专门试探诱导性说法。
这层暴露的东西比分数更有价值。第一次写标准时，两条他们以为兼容的准则在“漏服怎么办”上直接打架：一条要求拒绝并转诊给临床医生，另一条要求用说明书里的通用事实做安全回应。一个提示词没法同时满足两条。也正因如此，模拟对话层目前的评分标准还是工程起草的，在临床医生签字之前，它不参与发布门禁，也不支撑任何安全声明。
还有一条工程纪律：他们没有独立的评测脚手架，原则是“我们发布的就是我们测的”，所有评测跑的都是患者真正说话的那张图。代价是麻烦，收益是脚手架不会和线上漂移；副产品是换供应商变得便宜——同一套数据集对着不同配置各跑一遍，一次前沿供应商迁移只花了原来数周里的一天。
搬到施工方案审查：调度层只认状态，专业判断下沉
两个案例合起来给的是一条可操作的分界，落到施工企业的专项方案审查上，可以这么切。
编排层做三件确定性的事：认状态（这份方案属于哪一类、走到哪一关、附件齐不齐）、收字段（工程部位、结构形式、荷载取值、施工时序这些必填项）、跑可靠性闸（有没有生效的规范变更告警、这个风险等级要不要总工签字）。它不该判断脚手架搭设方案本身对不对。专业判断下沉到按分项隔离的专项智能体：临时用电、深基坑、起重吊装各自只加载自己那个领域的规范条文与工艺标准，互相看不见，也就不会把基坑的降水要求套到吊装上去。
第二件事是把验收标准从模型里拿出来。方案审查里有一批条目是能判定的：连墙件间距、扫地杆高度、剪刀撑角度、荷载取值与计算书里的数字是否互证。这些可以直接写成规则脚本当第一把尺，跑在提交之前。剩下那些靠整场对话形状才能判的（措施与规范条目对不对得上、与总进度有没有冲突、交底说没说清楚），可以学 Numan 的做法做成按类别打分的主题数据集——类别先按退审理由分，不要先算一个总分。最关键的一条是签字的归属：涉及结构安全与强制性条目的评分标准，得由总工和质量部门签字并标版本号，就像 Numan 那条边界归临床医生一样；工程师起草的标准可以拿来跑通工具，但不能拿来当放行依据。
成立条件也要说清。这套做法要求审查对象有稳定的分类和字段，如果项目上的方案格式各写各的，编排层连状态都认不出来，第一步该做的是统一模板而不是上智能体。知识文件也得有人维护，对应的那批规范条文与工艺标准需要一个责任人和一份修订记录。另外，专项之间互相隔离意味着跨专业的冲突（比如吊装路径与脚手架位置打架）不会被任何单个专项看到，这类问题得单独留一道跨项核对的工序。
两个可以先做的小试验
第一个只测值不值得建。找三十份已经审过的专项方案，只挑规范里可量化的条目，用一段规则脚本跑一遍，跟当初审查意见对照，统计两把尺不一致的条目有多少、其中多少是真问题。这个分歧率决定了规则脚本值不值得长期维护。
第二个测标准放在谁手里。挑一类高频方案，把退审理由按类别整理成一份评分标准草稿，先由工程师跑一遍，再交总工改一遍并签版本号，对比两版结论差在哪几条。这一步做完，那批“必须有人签字”的条目才算真的划出来了。
来源与说明
[1]: The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do —— Engineering at Meta / 2026-10-19 (https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/) [2]: How Numan Built an Eval-First AI Health Coach with LangGraph and LangSmith —— LangChain Blog / 2026-10-19 (https://www.langchain.com/blog/how-numan-built-an-eval-first-ai-health-coach-with-langgraph-and-langsmith) [3]: The Thin Orchestrator: How Meta Routes Agent Work Without Overloading the Router —— DEV Community（第三方拆解） / 2026-10-19 (https://dev.to/mech_app_ai/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router-34e7) [4]: 同上（另一转述站，含官方原文未载的幻觉率与成功率数字） —— worldprogramming / 2026-10-19 (https://www.worldprogramming.org/posts/the-thin-orchestrator-how-meta-routes-agent-work-without-overloading-the-router-ql9ppv) [5]: Meta shares internal architecture for more reliable AI agents —— Splitfeed / 2026-10-19 (https://www.splitfeed.ai/story/meta-shares-internal-architecture-for-more-reliable-ai-agents) [6]: Meta splits one AI agent into 14 specialists to cut hallucinations —— Splitfeed（含 PPC Land 与官方博客两条来源） / 2026-10-19 (https://www.splitfeed.ai/story/meta-splits-one-ai-agent-into-14-specialists-to-cut-hallucinations) [7]: How Numan Built an Eval-First AI Health Coach（全文转载，便于核对细节） —— worldprogramming / 2026-10-19 (https://www.worldprogramming.org/posts/how-numan-built-an-eval-first-ai-health-coach-with-langgraph-and-langsmith-laqska) [8]: Hacker News: the stories that passed 50 points（2026-10-19，含当日社区讨论） —— crosswalk / 2026-10-19 (https://crosswalk.to/crosswalk/hn-news) [9]: Weekly AI Digest · October 19, 2026（长时运行智能体的工程取舍线索） —— DEV Community / 2026-10-19 (https://dev.to/gksu_demirci_56f752953e7/weekly-ai-digest-october-19-2026-29b0) [10]: Multi-Agent AI Cost vs ROI in 2026（多智能体成本核算框架，用于校准代价一节） —— InfotechLead / 2026-10-19 (https://infotechlead.com/artificial-intelligence/multi-agent-ai-cost-vs-roi-in-2026-why-enterprises-pay-5-10-times-more-and-which-deployments-deliver-results-98986)
检索截止：2026-10-20 05:50（Asia/Shanghai）。Meta 的架构数字与引语出自官方工程博客，转载站点给出的幻觉率与成功率数字在官方原文中查无，已在正文标明；Numan 的评测做法出自 LangChain 客户博客，其模拟对话层仍为原型、评分标准尚未由临床医生签字，正文已按原文限定；施工企业的迁移设想与两个小试验为本文提出，未实施。