五百万条信号压到五个告警：智能体该在哪停手

一座 AI 数据中心里，进风温度、冷却液流量、风扇转速一直在采样。把这些通道加起来，CoreWeave 自己的机房每天产生大约五百万条信号。运维团队看不完这个数，你的运维团队也看不完。问题于是换了形状：谁来看不再关键，关键是什么东西去看。他们的答案是两套：一条离线的检测管线，一个在线的解释智能体。这个分工值得细讲，因为它把多数团队混在一起的两件事拆开了。

每天五百万条信号，收敛成五个告警

五百万条里真正要人的只有大约五条。CoreWeave 在 10 月 15 日的工程博客里写得很直白：检测走确定性路线，解释和处置建议才交给模型。

检测必须对同样的输入给同样的答案，因为它一天要重复几百万次。一条「这个节点是不是在坏」的判断，如果周二和周一不同，运维就没法排班，也没法复盘。

解释一个告警是另一类问题。「真的吗、什么引起的、先查哪里」，这些没有能事先写好的流程。有用的流程，是见过这个案例之后才写得出来的。所以这一半交给智能体。它拿到信号窗口、相关信号和节点在集群里的位置，可以查历史遥测、拉节点信息、检索旧事故。

这就是两类问题必须分开的原因。这跟模型好不好没关系，问题在两类要求正好相反。换句话说，同一套东西不能既做判定又做解释。一个要每天五百万次的稳定，一个要每一次都应付新情况。塞进同一条路径，慢的那头会把快的拖死。

智能体是在造工具，还是就是那个工具

这句区分可以直接当检查项用：系统跑起来的时候，智能体还在不在。

用智能体造工具，它离线跑，探索数据、装配并调优一条管线，交付的是那条管线。运行时它不在现场。用智能体当工具，它待在运行路径里，被实时调用。拿掉它，系统就停。前者的输出永远一致，后者不保证。

成本曲线也相反。造工具一次很贵，之后每处理一个数据点都很便宜。也就是说，贵的部分买的是可重复性。当工具一开始很便宜，之后每次调用都要付钱，延迟跟着流水涨。多数团队默认选后者，因为它上手最快，一个季度就能做出演示。代价推迟到规模上来那天：五百万条信号乘以一次推理，账单和排队时间按这个乘法长大。

还有一笔账更容易漏。当工具时，行为随模型版本漂移，每换一次底座就要重验一遍。造工具时，漂移停在交付那一刻，之后跑的是能 diff 的代码。这笔账在采购时看不见，在第二年换模型时一次付清。

设计在工作环境里，不在提示词里

给智能体的不是提示词，是一套工作环境。它能分析遥测、造特征、训练候选模型，并对固定的留出事故集给自己打分。它可以重写代码，不能移动目标。循环到指标不再提升，上线前有人复核。

听着像原则，落地时最费功夫的部分全在模型之外。哪些信号真携带故障、该怎么表示，是他们和跑机队的工程师坐在一起谈出来的。「什么叫一次真事故」这条定义也是人给的，智能体拿它给自己打分。他们写了一句话，值得照抄：把智能体指向一个复杂系统而不给需求，它会检测出很多东西，但没有一件有意义。

在线那一半的约束换了形式。被要求凭记忆解释告警，模型会给出一段听起来合理、有时是编出来的话。他们的做法是让它不能凭记忆回答：每句结论必须来自一次实际执行过的工具调用。这不能保证答对，但工程师能查到这句话从哪来。换句话说，可追溯在这里就是验收标准。

还有一条写得很干脆：它不做动作。根因判断可以错，而在活着的集群上，这个错的代价远高于自动化的便利。所以每条建议都带证据交给人。任何能碰物理设施的系统，都要写明它能做什么、何时能动、何时必须人批。

有一个副产品容易漏。检测精度是设计前提，不是优化目标。一天报一千件事的检测器，比没有用更糟。运维会停止阅读它，真事故就落在没人信的队列里。只让智能体看已被标记的事件，成本小了，注意力也收住了。

一次建得贵，然后越跑越便宜

结果是反直觉的组合：一个非确定的过程，交出了一个确定的工件。智能体每次都不太一样，它交出来的东西不变。特征定义、模型权重、阈值、后处理，都是普通代码加一个固定模型。可以版本化，可以 diff，上线前可以被人读。同一条信号跑两次，答案永远一样。一天五百万次也一样。

更值得记的是这条线会动。博客里有一段：推理侧的智能体看到同一类异常第二次出现，判断它已经稳定到能用一条确定性规则描述，于是提出一条规则。这条规则交给拥有那块硬件的工程师，由他判断它描述的故障值不值得报警。也就是说，一个当工具用的智能体，用着用着自己变成了造工具的那个。

他们把规律总结成一句成本判断：多数智能体部署越扩越贵，这一套设计成越跑越便宜。原因不神秘。贵的部分开始时付一次，便宜的部分每次判断都复用。工作从「贵而灵活」开始，被证明可重复的部分固化，挪到「便宜而可预测」那边。这条线不是靠模型变强自动挪的。它靠人批准，一次挪一格。指望模型升级顺手把这条线挪对，通常挪不准。

十万行包装的终点，是升级不了

第二个材料是反面。Respan 今年 10 月在 Hacker News 发布了一个 Rust 写的开源网关，核心很小。供应商、协议、模态、网关功能，全部做成插件。他们讲了自己的来历：从 2024 年起基于 LiteLLM 做，服务了数千家组织。每家要的 key 设置、路由、限额都不同，包装层一路加到某个阶段超过十万行。

今年 1 月，一次例行的 LiteLLM 升级造成间歇性连接错误。只能回滚，原因至今没定位到。此后他们不再原地升级上游，改成手工挑 backport。他们自己的结论是：继续给上游打补丁撑不下去。这句话的分量在于，说话的人已经这样干了两年。

最该记的不是行数，而是技术债在这里长成什么形状。它不表现为慢，表现为不能动。升级做不了，缺陷要穿过十万行自家代码去定位，任何一次上游变更都变成一次风险评估。判断团队有没有越过这条线，有个朴素的检查：手上那个上游依赖，能不能在一个发布周期内升上去。做不到，说明控制权已经不在自己手里。

反过来看他们的新结构，能不能扩展是写进结构的。核心只负责事件分发。一个供应商是一个短文件，Mistral 那个 22 行，每个特殊行为配一个测试。他们把扩展边界当第一设计目标，不是功能清单。这也对上这个市场的另一半事实：网关这层正在被平台厂商收编。Palo Alto Networks 4 月 30 日宣布收购 Portkey，5 月 29 日完成。Mintlify 3 月 3 日收购 Helicone，Helicone 随后转入维护模式。控制平面归了平台厂商，靠「支持多少家供应商」当卖点的窗口基本关上了。

对买方的推论很直接。别问一个网关支持多少家供应商。问它的上游能不能升级，改动能不能 diff 出来，手工补丁堆了多少个。这三个答案决定三年后你是在升级它，还是在绕开它。

以为关掉的代码，还在吃内存

第三个材料跟智能体无关，但它补上这条界线的另一半。声明和实际执行之间的差，只能用测量消除。

Cloudflare 10 月 9 日给 Workers 和 Durable Objects 上线了按需 CPU 与内存分析。可以在控制台或命令行抓一段生产流量，出交互式火焰图，也能下载 pprof。CPU 采样器每毫秒采一次。运行时只在启停时短暂持有隔离锁，其余时间不阻塞流量。

他们举的第一个例子是自家的一个 Worker。它的 P999 内存停在 133MB 左右，而 Worker 的上限是 128MB。所以它频繁被驱逐，报的是内存超限。团队知道内存是问题，不知道是代码的哪一部分。问题在于，他们以为自己已经关掉了。堆分析打开之后，pprof 显示 Prometheus 那段代码占了大约 66.7% 的分配。而这段代码本来应该已经关闭了。

实际情况是只关了一半。它还在给 Worker 的大量代码路径做埋点。采集到的数据从未离开这个 Worker，但内存成本照付。团队把这条路径整个删掉之后，P50 从 70MB 降到 54MB，P90 从 94 降到 79，P99 从 113 降到 97，P999 从 133 降到 118。比上限留出大约 10MB。

第二个例子更细。R2 绑定的那个 Worker 里，一个叫 genericR2JsonReplacer 的函数占了 5% 以上的 CPU。原因是它被 JSON.stringify 逐节点调用时，自己又在遍历整棵树。一个嵌套五层的值被处理了五次。修掉重复工作，这个函数快了 2.7 倍。另一处是一次重复的 metrics 调用，单次就占 1% 的 CPU。把结果存进变量就省下来了。

这三个数字该放进一篇讲智能体工程的文章，因为智能体系统正好落在传统监控最不敏感的位置。进程常驻，CPU 突发，内存吃长尾。看板告诉你内存高了，只有分配级分析告诉你哪一行在吃。这就是为什么这件事只能用测量做，不能靠读代码推断。更重要的是一句反直觉的事实：关闭不等于没跑。这一条对你停用的插件、注释掉的钩子、以及「我们已经把它禁了」的配置项同样适用。

一条界线，三次测量

三份材料拼起来是同一件事。可守的位置在模型外面那层工程，守住它的关键落在界线写得清不清楚、测不测得了，不在代码量。

这条界线有三个刻度。哪一段必须确定，在运行路径上做判定。哪一段可以推理，负责解释、建议和查证。哪一段是扩展，放在插件、脚本和配置里。每段都要配一个测量。否则声明只是声明。

第一个刻度用留出事故集测。目标固定，手段放开，任何候选都在同一个留出集上打分。第二个刻度用工具调用证据测，每句结论都要能指回一次实际执行。第三个刻度用分配级分析测，停用之后重抓一次，看 P50 和 P99 有没有跟着降。三条都不依赖模型供应商。这是它们的价值：换底座不用重做。

有一条旁证。arXiv 上 5 月的一篇预印本做的正是这件事。不改模型权重，只改运行时的工作环境。作者把一个叫 Life-Harness 的 harness 从训练轨迹里演化出来，再把 harness 固定住，用它看没见过的任务。

他们在 AgentBench、τ-bench、τ2-bench 和 AppWorld 的八个环境、18 个开源底座上测过。用 Qwen3-4B-Instruct 时，平均准确率比 Meta-Harness 高 28.7 个百分点，比 AHE 高 7.5 个百分点。优化用的 token 分别少 8.5% 和 68.4%。同一套 harness 换到 GPT 5.5、Opus 4.8 和 Gemini 3.1 Pro 上，平均还能涨 3.5 个百分点。

这组数字要分清它证明什么。它证明工程层模型无关、可以单独测。它不证明 28.7 个百分点会出现在你的业务里，那八个环境都是规则明确的确定性任务。换到需求含糊的现场，收益会掉到 3.5 个百分点那个量级。这是预印本，作者自报，没有同行评审。

我们自己也核了一遍手头的东西。我们的运行时代码是上游的 git 克隆，跟上比对是 0 ahead / 0 behind。HEAD 停在 10 月 22 日，工作区只有两个未跟踪项。换句话说，今天我们的分叉成本是零，能力全部落在脚本、插件和技能这一层。这条状态有现成的检查命令，git rev-list --left-right --count HEAD...@{u}，它应该长期保持 0 0。理由就是 Respan 那条。分叉一旦开口，每次升级都要重付一次评估成本。付到某天就付不动了。

这套做法不证明什么

边界要写清楚。CoreWeave 的数字来自他们自己的博客，而且他们正在卖物理 AI 的现场工程服务。属于利益相关的自报。五百万到五这个比例是他们机房的规模，不是你业务的规模。

Respan 的十万行是他们的历史，不是行业统计。他们自己的网关还是 pre-alpha。Cloudflare 的 66.7% 和 2.7 倍是两个具体案例，不是普遍比例。按需分析还需要生产流量，低流量的版本抓不到样本。那篇预印本在不同底座上差别很大，跨环境迁移的收益只有 3.5 个百分点。

可以迁移的是机制，不是那些百分比。机制有四条。在线路径只放确定性判定。推理侧每句必须来自一次工具调用，而且不直接动作。上游依赖保持可升级，扩展只发生在插件层。停用之后重新测量，不能凭配置推断。这四条不需要 CoreWeave 的机房，也不需要 Cloudflare 的运行时。任何准备让智能体接手真实动作的现场都能用。

我们的判断

我们的判断是：模型外面那层工程可守，但守得住的不是代码量，是三条能被测量的界线。理由很直接。模型会换，供应商会涨价，网关会被平台厂商收走，这三件事过去一年都发生过。而「哪一段必须给同样的答案」这个问题，只有拥有那套系统的人回答得了。

由此有三条能落地的动作。第一，立项时写一份 harness 规格。写清三样：目标固定项，也就是考核集与判定标准；手段开放项，也就是允许智能体改什么；证据要求，也就是每条结论必须附带哪次调用。评审看这份规格，不看提示词。

第二，给上游依赖设一条升级预算：每个发布周期至少要能升一次。升得动，说明扩展边界还在自己手上。升不动，说明包装层已经越线，该把能力挪到插件层，而不是继续加包装。第三，把「关闭」当成待验证状态。任何停用的功能、插件和钩子，停用之后抓一次分配分析，把 P50 和 P99 记进变更记录。这一条最便宜，也最容易被跳过。因为「我已经关了」听起来像已经完成的事。

留给你的问题是：如果把模型换掉，你系统里哪一部分的行为不会变。答得出来，那部分就是你的位置。答不出来，位置还在别人手里。

参考来源

CoreWeave Engineering，《Agents on live hardware: reason where you must, engineer everywhere else》，作者 Joël Henry，2026-10-15（五百万条信号与五个告警、两种用法对照、留出事故集与工具调用证据的要求、推理侧提出规则的经过均出自该文）

Hacker News，《Launch HN: Respan (YC W24)》，2026-10（十万行包装、2026 年 1 月升级故障与手工 backport 出自作者自述）

Respan Gateway 源码（MIT / Apache-2.0，pre-alpha；插件结构与供应商文件长度以仓库为准）

Cloudflare，《Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects》，2026-10-09（P999 133MB 与 66.7% 分配占比、删除后的四档内存读数、genericR2JsonReplacer 快 2.7 倍均出自该文）

Palo Alto Networks 新闻稿，完成对 Portkey 的收购，2026-05-29

Tianshi Xu 等，《Adapting the Interface, Not the Model: Runtime Harness Adaptation for Deterministic LLM Agents》，arXiv:2605.22166（预印本，作者自报数据）