https://icorer.com/icorer_blog/categories/ai/Recent content in Ai on 旁注旁观Hugozh-cnWed, 11 Nov 2026 14:12:52 +0800https://icorer.com/icorer_blog/posts/ai/sag2-embedding-free-retrieval/Wed, 11 Nov 2026 14:12:52 +0800https://icorer.com/icorer_blog/posts/ai/sag2-embedding-free-retrieval/语义判断可以挪到提问之后。索引只留词与词频，一个 SQLite 文件，建库 2.36 秒，MuSiQue 的 R@10 从 54.41 抬到 86.62。 原文是《SAG2: Embedding-Free Multi-Hop Retrieval with BM25 and JEV》，Zleap AI 的 Yuchao Wu，arXiv 编号 2610.22588，全文 15 页（arXiv 页面 ，PDF ）。代码在 Zleap-AI/SAG-Benchmark 。它是同一位作者前作 SAG 的续篇，SAG 用 MySQL 存事件与实体、用 Elasticsearch 存向量，这篇把两者都去掉。下面每个数字都能回到原文的表号，凡是我自己除出来的都标「我算」。 一、埃里克·霍特的出生地# 附录 A 里有一道具体的题，问埃里克·霍特出生在哪。语料里有一段讲霍特本人，它直接命中问题，也进了 BM25 的前一百。另一段讲蒙特贝洛，纽约州的那个地方，只有在知道「霍特出生在蒙特贝洛」之后才有用，而它和原问题的词重叠几乎为零，前一百里没有它。 SAG2 的流程是这样转的。种子只能从高分段落里取，霍特那段正好在里面。种子正文里的「蒙特贝洛」被当成一个可用的词，权重按四个因子算出来，然后拿这个词单独去查一遍索引，蒙特贝洛那段就进来了。最后十条里两段都在，这道题的召回从 50% 变成 100%。 这道题不是孤例。一千道 MuSiQue 题里，有 389 道的最终结果包含至少一段不在初始 BM25 前一百里的证据，这样补进来的段落一共 433 段。BM25 的 R@10 是 54.41，套上这套流程是 86.62。 指标 BM25 SAG2 差 MuSiQue R@10 54.https://icorer.com/icorer_blog/posts/ai/jev-harness-design/Wed, 11 Nov 2026 07:16:58 +0800https://icorer.com/icorer_blog/posts/ai/jev-harness-design/2026 年 9 月一份围绕 Jev 的设计笔记，用一句话把编码 agent 的六个毛病收在一起。假如语言模型没有 KV cache，今天这些 agent 会写成什么样。答案不在更强的模型上。它要求有人决定，每一轮往模型面前放什么。 片子两分多一点，中文配音，字幕烧在画面里，也可以用播放器关掉。 一、一个反问，六个症状# 今天的编码 agent 大多是一个循环、一个模型、几只工具。真正决定它好不好用的东西不在这个循环里，而在循环每转一次时递给模型的那段文本。 KV cache 是这段文本写成追加式记录的原因。复用缓存前缀几乎免费，改动靠前的任何一个字节，后面全部要重算。这条经济学没有写进任何设计文档，它写在账单里，并且决定了几乎所有主流 agent 的骨架。 把缓存当成不存在，会同时发生两件事。一是可以按状态显式设计，上下文是组装出来的。二是六个一直被人抱怨的缺陷露出同一个底。 症状 为什么它会存在 代价 路由失败 交回大模型时上下文被重算 混合路由比纯 frontier 更贵 工具挤占上下文 schema 必须常驻系统消息 无关工具的 token 照付，选择还更差 压缩压在问题之前 假设所有轮次共享一份状态 查询无关的压缩丢掉后面要用的信息 子 agent 很少启动 传什么进去、合并什么回来很难 并行度低 重启丢掉状态 有状态的记录会漂移 坏状态和好状态一起扔 内置能力之争 每个内置永久占用上下文 在易用和强大之间二选一 这份笔记给替代方案留了一个位置，叫 Jev。它不写代码，坐在模型旁边当决策层。harness 把当前状态交给它，包括目标、上下文、规则、可用动作和已执行动作，同时给一个预设问题，它返回类型化答案，取值为 choice、score 或 noul，各带一个概率。类型化带来的是可校验，harness 能卡阈值、能分支，不用解析散文。 轻点放大 笔记把这套东西压成一张表，六个高频决策点，一个问题一个类型化答案。 决策点 问 Jev 什么 返回什么 上下文 这一段对这个查询该有多可见 隐藏、短摘要、长摘要、全文 缓存 复用前缀还是重建 noul 加概率 路由 这个子任务能不能离开 frontier 选择加成本估计 工具 哪只工具对得上这个意图 排序结果，取前 k 权限 这条命令能不能跑 允许、询问、拒绝 安全 这个任务会碰哪些文件 敏感度分数 六个问题每轮都问，一次会话里问上千次。笔记把杠杆放在这个位置，模型那边没有。https://icorer.com/icorer_blog/posts/ai/mopd-token-share/Tue, 10 Nov 2026 07:02:51 +0800https://icorer.com/icorer_blog/posts/ai/mopd-token-share/TRL 的多教师在线蒸馏示例跑了 60 步。指令跟随拿了 20% 的 prompt，训练 token 只分到 1% 到 3%，它是三科里唯一没学动的。Open-MOPD 那篇论文把这个现象叫 token 预算错配，修完之后可回收的能力上限从 35.6% 提到 83.4%。 片子一分五十八秒，中文配音，字幕烧在画面里。 一、六十步之后，只有一条线没动# 2026 年 11 月，Hugging Face 的 Sergio Paniego 把 Open-MOPD 放出的三个专家接到 TRL 的 AsyncDistillationTrainer 上。学生是 SmolLM3-3B 的 SFT 检查点，三个教师分别用 GRPO 在数学、代码、指令跟随上训过。跑 60 步，大约是论文训练量的百分之一。 训练日志里出现两件事。teacher_token_frac 显示指令跟随每步只拿到 1% 到 3% 的训练 token，而它在 prompt 里占 20%。teacher_jsd 显示学生到数学、代码两个教师的距离一路往下，到指令跟随那个几乎是一条平线。 评测端跟着这个形状走。 模型 AIME24 AIME25 IFEval MixSFT 起点 17.5 19.2 67.5 60 步 MOPD 24.2 22.5 73.https://icorer.com/icorer_blog/posts/ai/ontology-evolution/Mon, 09 Nov 2026 11:08:09 +0800https://icorer.com/icorer_blog/posts/ai/ontology-evolution/2025 年 12 月到 2026 年 11 月，六篇论文从三个方向收口到同一个结论。本体构建的瓶颈已经从「谁能把本体写出来」移到「谁能证明写出来的东西是对的」。下面每一个数字都能回到原文的某一节或某一张表。 片子两分十九秒，中文配音，字幕烧在画面里，也可以用播放器关掉。 一、同一个事故，现在可以量了# 一支队伍把 40 张表的关系库交给模型，生成一版本体。人工审了两天，改掉三分之一，剩下的签了字。三个月后有人问，某条 subclass 关系是哪来的，没人答得上来。它可能是从外键推出来的，也可能是从邻表名字猜的，区别在事后无法分辨。 这件事过去只能靠经验描述。2025 年 12 月，Burr 给了第一套统一的度量，54 个手工场景加 4 个真实数据库（PACMMOD 3(6) 第 305 篇）。2026 年 7 月，一份系统综述数完了这个方向的 30 篇论文、41 项研究（Semantic Web 17(4)）。2026 年 11 月 2 日，LLMs4OL 第三届的赛道报告发布，13 支队伍上榜。三份材料的规模差得很远，指向的问题一样。 轻点放大 二、第一个统一基准打碎了模型通吃这条说法# Burr 的 §1 先算旧账。作者按 Mosca 等人的方式复查了十个本体学习系统，结论是多数论文根本不评测，或者只做词法比对，连 F1 怎么算都不写。 他们的解法是把评测绑到 mapping 上（§4）。一个本体光有类名不算数，还得说清它对应数据库的哪张表、哪一列，真阳性按 mapping 算。这个改动把「名字像」和「指对了」分开，也顺手把词法 F1 的虚高暴露出来。 微基准（§6.2.1）的结果是这样。 系统 微基准 mapping F1 备注 Gemini 2.5 Pro，checklist 提示 0.https://icorer.com/icorer_blog/posts/ai/evals-honest-numbers/Mon, 09 Nov 2026 07:36:00 +0800https://icorer.com/icorer_blog/posts/ai/evals-honest-numbers/一个 eval 的钱主要花在读输出和标用例上，代码只占很小一块。这篇把它拆成四个部件，每个部件配一个可以自己复算的数字。 片子一分五十五秒，中文配音，字幕烧在画面里，也可以用播放器关掉。 一、两条规则放过的回答# 一家卖自行车和露营装备的网店，客服工单进到模型里。工单说，我上周退了车，退款还没到账，你们自己写着五个工作日。 系统的回复很客气，四段，引用了退换货那一节，两个必含事实也都在，五个工作日和二手商品 15% 的折旧费。两条代码规则同时放行，一条查有没有引用章节，一条查必含事实齐不齐。 模型判官判它失败。它多写了一句「总额度最多 15 个工作日」。 作者在 60 条测试用例上重跑了一遍，只有 11.7% 的回复能通过全部代码规则，而代码规则一条编造的断言都没抓到。这两个数字摆在一起，就是 eval 存在的理由。一段格式和引用都挑不出毛病的话，可以同时是错的，而错的那部分恰好是客户会当真照做的部分。 轻点放大 二、四个词，四条路# 概念 测什么 例子 常见误用 eval 你的系统在你的数据上 这个助手跑 60 条工单 拿它跟别人的模型比 benchmark 一个模型在一套公开题上 GSM8K、SWE-bench 拿它选产品路线 test 一个函数有没有返回预期值 JSON 能解析、不崩 以为通过就是对的 monitoring 上线之后的真实流量 每天抽样评一批工单 只在出事的时候看 四件事的差别不在精度，在数据归属。benchmark 的题是别人出的，eval 的题得你自己攒，攒不出来就没有 eval。原文给了一个比喻，模型是引擎，eval 是你的车在你这条路上的表现。这个比喻站得住，因为它顺手解释了另一件事，引擎评测拿第一的模型，到你这里答错客户的问题，两件事并不矛盾。 三、先读输出，再写判官# 任何自动判官动手之前，先把输出读一遍。作者读的是 60 条测试回复，逐条记一句失败原因，再把笔记并成类别。这批数据的结果是这样。 结果 条数 通过 34 缺必含事实 15 有编造的断言 12 检索到错误章节 8 没有回答问题 5 数值写错 2 过度承诺 1 60 条里 34 条通过，勉强过半。最大的两个问题合计 27 条，从 demo 里完全看不出来，因为 demo 只看一条。这张表就是后面所有判官的需求文档，按频次从高到低建。给不发生的失败写判官，得到的是一个好看但没用的数字。https://icorer.com/icorer_blog/posts/ai/decisionrag-retriever-free/Sun, 08 Nov 2026 12:06:43 +0800https://icorer.com/icorer_blog/posts/ai/decisionrag-retriever-free/检索的瓶颈不在候选池有多大，而在你让模型看见什么、以什么顺序看。DecisionRAG 把打分换成问路，2.68M 段的语料 1.7 秒给出 65.4 的首位命中；它同样清楚地输掉了三格。 中文配音版，2 分 53 秒。中文与英文两版内容一致。 原文是《Retriever-Free Retrieval: Navigating Documents with Decision Models》，Cornell 与 ASAPP，arXiv 编号 2610.35868，全文 21 页（arXiv 页面 ，PDF ）。下面每个数字都能回到原文的表号或附录号，凡是我自己算出来的都标了「我算」两个字。 一、错的那一条，排在第一# 论文开篇是一个具体的查询。诺兰在 2000 年拍的那部电影，主角是谁。BM25 和稠密检索都会把《角斗士》排到前面去。它也是 2000 年的电影，词像，向量也像。真正能回答问题的《记忆碎片》排在后面，甚至不在前几名。 检索器的接口只有一种比法，把查询和每个候选单独比一次。生成器已经换了两代，检索器还在做词频和余弦。 环节 现状 后果 词频 BM25 在 MultiDoc2Dial 上 R@1 20.6 词重合不等于可答 稠密 Qwen3-Embedding-8B 27.9 召回上限由一阶段定死 重排 8B 重排器把 27.9 抬到 33.6 只能重排已经给它的候选 生成式重排 GPT-5 重排 dense top-20 到 47.5 贵、慢，仍是两段式 论文把这件事叫作能力不对称。检索器漏掉的证据，生成器再强也捞不回来。这个判断没什么新意，有意思的是它选了哪条路来修。 二、之前到哪一步了# 修这条路有三族做法。 一族 代表 天花板在哪 一阶段 + 重排 BM25、SPLADE++、Qwen3-Embedding、BGE、Qwen3-Reranker-8B 重排的输入永远是一阶段给的 100 条 生成式 listwise RankGPT 一路，GPT-5 重排 一次只能看 20 条，成本按 token 走 让 LLM 走层级 MemWalker、PageIndex、LATTICE 每层都要生成一串编号，慢 第三族离这篇最近。它们已经有层级，也已经在每一层做选择，只是选择的方式是「生成」。同一套层级、同一套预算，换成 GPT-5 逐字写出要保留谁，在 ConditionalQA 上要 28.https://icorer.com/icorer_blog/posts/ai/graph-serialization-15-formats/Sun, 08 Nov 2026 12:01:41 +0800https://icorer.com/icorer_blog/posts/ai/graph-serialization-15-formats/一句话。图怎么写进 prompt，是一个能测量的系统参数。抽取任务上它值 1.3 到 3.9 个百分点，结构化推理上值 28.4 个，而同一个模型家族里三个推理档位各有各的最优写法，最准的那一档用的 token 反而最少。 一、先把这一步的价格量出来# 假设你在做一件很普通的事。用户问了一句需要多跳才能回答的话，你的检索器从图数据库里捞出两跳邻域，封顶 450 条三元组，然后把这堆东西塞进 prompt。 塞进去的方式，你大概率是随手选的。json.dumps 一下，或者抄一段 turtle，或者干脆写成「A 认识 B」的句子。这篇文章说，这一步的选择能让同一个模型在同一个问题上的准确率差 28.2 个百分点。 数字来自 Oracle 的 Julien Yu、Mihaela Bornea、Avirup Sil、Katrin Kirchhoff 四位作者，论文投在 EMNLP 2026 Findings。他们在 110 道 Wikidata 题上跑 gpt-5.4，把子图和问题都固定住，提示也一字不改，只换序列化格式。jsonld 拿到 41.8%，adjacency 拿到 13.6%。 这件事不是第一次被量。TLAG 在合成图上报过 4.8 到 61.8 个点的差距，KG-LLM-Bench 在知识图谱理解任务上报过 17.5 个点。这篇要做的是把设计空间铺开，把推理档位算进去，再补一个真实子图的实验。 二、十五种写法是哪十五种# 论文按语义显性度把格式分成六个家族，共十五种。这十五种都是作者手写的序列化器，不对应现成库里的某个标准格式。 家族 格式 暴露什么 语义网与约束视图 turtle jsonld shacl_lite 类型、谓词、域与值域约束 结构化自然语言 text2kgbench entity_centric relation_indexed 实体与关系的可读描述 表格 markdown_table toon 节点表和边表 图语言 mermaid dot 拓扑的画法 连通性编码 adjacency edge_list structured 邻接关系本身 散文 nl_summary friendship 用句子讲一遍图 差别有多大，看两段就好。同一张五节点的小图，structured 写成两行集合。https://icorer.com/icorer_blog/posts/ai/agent-economy-project-eve/Sat, 07 Nov 2026 11:25:06 +0800https://icorer.com/icorer_blog/posts/ai/agent-economy-project-eve/一句话：这不是一次"AI 打游戏"的评测。它第一次把 Agent 经济体拆成可以记账的三层——执行效率、工具资本、信任成本——并且给出了每一层的单价：模型换代四个月，收益三倍；脚手架换作者，从天天沉船到十二小时零损失；而一个被指派的破坏者，几乎没有人能抓到。 一、为什么这次实验值得当真# 多数"AI 做交易"的演示，测的是模型背没背下来历史行情。EVE Online 不适合背，因为它的价格由玩家自己挖、自己造、自己打捞出来，报价簿参照 NASDAQ 设计，每天有超过 15,000 种商品在流转，而单个贸易枢纽（Jita）的体量约是第二大枢纽的十倍。这条供应链的中间层——矿物、精炼、组件、船坞、燃料——在二十三年里长出了巨型工程、战争经济、避税天堂和公司渗透。 换句话说，它同时具备了两样东西：一个真实摩擦的市场，和一套必须靠组织与信任才能运转的生产关系。而这两样，恰好是"Agent 经济体"这个词底下最难拆开的两半。 Anthropic 与 Fenris Creations 合作，让 Claude 在两个场景里各待了一段时间： 场景 任务与时间尺度 关键约束 EVE Online（模拟器） 单人交易，只求利润最大；两周 × 9 窗、六个月 × 2 窗 30 亿 ISK、5.6% 往返费、真实订单重放 EVE Frontier（线上） 四人一队，做教程与造舰；数小时到数天 亚秒战斗、情报会过期、船沉了回裸船 不干预真实玩家的原因很干净：自动交易在真实服务器上违规，所以市场部分用重放模拟器；Frontier 还在开发期、世界会定期重置，所以允许线上跑。这个边界很重要，它决定了后面哪些结论能外推、哪些不能。 二、实验一：三十亿 ISK 的做市商# 先看难度。买进再卖出，往返摩擦约 5.6%。在买卖双方都密集的商品上，市场已经足够有效，价差薄到没有肉。研究团队先跑了 20 多条规则策略作为基线，跨 9 个两周窗口——只有一条勉强不亏，而且只是勉强。 然后是模型。同一套环境、同一笔本金： 模型 两周期平均收益 六个月平均收益（相对本金） Opus 4.6 约 +4%（与最好的规则策略持平） 约 200% Opus 4.7 +16% — Opus 4.8 +22% — Fable 5 +43% 约 600% Opus 4.https://icorer.com/icorer_blog/posts/ai/agent-memory-stack/Fri, 06 Nov 2026 22:10:00 +0800https://icorer.com/icorer_blog/posts/ai/agent-memory-stack/一句话　记忆不是把聊天记录存下来，而是在四层之间搬东西：下层真而难用，上层好用而易错；「梦境」（dreaming）就是那个在离线时段负责搬运、纠错与修补的工人。 本文的图按原文的数据与结构重绘；原文自带的十余张图表与截图，见文末的出处链接。 一、痛点：它能看见的只有这一次# 轻点放大 长期对话里的记忆问题有两个方向会同时发作：一是忘——每个新会话从零开始，上周的决策、踩过的坑、验证过的规则全没了；二是胀——为了不忘，把历史一股脑塞进上下文，于是注意力被稀释、成本上升、旧信息还和新事实打架。 Anthropic 在这篇文章开头借了克尔凯郭尔一句：生活只能倒着理解，却必须正着过。记忆设计撞上的是同一件事——在写下一条记忆的那一刻，你并不知道未来会不会需要它。所以真正难的是判断「此刻什么值得记」，以及「记错之后怎么改」。 文章对「agent 记忆」的定义很克制：只指 Claude 从经验（与用户的交互、被交代的任务）中获得、并能跨会话保留下来、作为上下文再读到的知识。它明确排除了另外三样：改权重、单次会话内的 in-context learning、以及压缩（compaction，用摘要替换旧轮次以便在新窗口继续）。 二、四层记忆栈# 轻点放大 把文章里的做法摞起来，是这样四层（这是本文的归纳，原文按主题分节，未画成这样的栈）： 层 是什么 谁写它 关键约束 1 原始层 会话记录（transcripts）、日志 系统自动 唯一的 ground truth；dreaming 拿它校验上面每一层 2 笔记层 规则、验证过的事实、踩过的坑 模型在会话中判断着写 写什么靠自己判断，比外部规则更有效（见第四节） 3 表征层 wiki：页 + 链接，相当于一张地图 dreaming 离线建、改、剪 会越写越大，甚至超过原文 4 注入层 每轮开头自动装载的常驻上下文 系统装载 + dreaming 上提 必须很小：Claude Code 只注入 MEMORY.md 前 200 行 / 25 KB 第四层的约束是全文最实用的一个工程结论：Claude Code 的自动记忆并不把全部记忆塞进每个会话，只加载 MEMORY.md 的前 200 行（或 25 KB），把这部分当作索引——告诉 Claude「你知道什么、去那里找」。原文还引了自己文档里的一条警告：指令文件越长，遵循度越低。所以顶层要小，dreaming 在顶层的主要工作其实是保持它小：把细节往下挪，只留链接。https://icorer.com/icorer_blog/posts/ai/agent-native-database/Fri, 06 Nov 2026 11:30:00 +0800https://icorer.com/icorer_blog/posts/ai/agent-native-database/一句话　数据库的头号用户从人换成了 Agent，于是它裂成两条腿：一条存状态、按需供给，一条供上下文、提前编译。真正变的不只是形态，是"检索"这件事的定义——从召回算法，变成编排框架加编译供给。 一、问题：报错是写给人看的# 先看一个不起眼的改动。Supabase 把自己全部报错信息翻出来重做了一遍：不再是 500 Internal Server Error，而是在返回文本里直接写明——你为什么触发这个错误、现在该执行哪条命令修、或者去读哪个 URL 的文档。 这个改动的动机是留存。人类程序员看到天书般的报错，会自己去 Google；Agent 看到同样的报错，会放弃并切到竞品。两家公司争的是"卡住之后它还愿不愿意再试一次"。 它暴露的是更底层的事：数据库的设计假设全部建立在"用户是人"之上。Dashboard 给人点，API 给人调，报错给人读，实例给人规划。把这些假设逐条拿掉，剩下的才是 Agent 需要的东西。 三个已经量化的断裂： 断裂 事实 来源 供给颗粒度 Supabase 周新建数据库 >100 万个，托管库从 800 万涨到近 5000 万（一年） 官网公布（YC 播客） 使用者身份 约 70% 的新增活动来自 Agent；72.1% 的组织已有 Agent 在生产运行 官网公布 / IDC FERS n=903 上下文成本 Agent 约 85% 的计算精力消耗在"重新发现"循环上，而非任务本身 Pinecone 估算 第三条最难缠。如果每次提问都要从零开始探索一遍语料，那么数据规模每涨一个量级，成本和延迟就跟着涨一个量级。 二、业界已经解决到什么程度# 过去 18 个月，这条线上发生的事可以压缩成五条可核对的主张，每条都带着后果。 主张 出处 后果 工具结果的交付方式比检索算法更能决定准确率；inline 交付下 grep 在每一个 Harness×模型组合上都胜过向量检索 PwC《Is Grep All You Need?https://icorer.com/icorer_blog/posts/ai/seven-layers-agent/Fri, 06 Nov 2026 09:20:00 +0800https://icorer.com/icorer_blog/posts/ai/seven-layers-agent/摘要　生产级 agent 的失败，绝大多数不发生在模型这一层。把「从模型到结果」的距离拆成七层——模型、指令与上下文、工具、记忆、循环、评测与护栏、人的签核——之后，最常见的那个动作（换模型、改提示词）恰好作用在唯一不太需要动的地方。本文重排了这篇指南的论证顺序，按证据强度给每条主张打了标，并补上它没谈的两件事：成本与可观测。 一、主张，和它的形状# 原文的骨架是一句招聘比喻：给一个天才新人一间没有入职培训、没有账号、没有笔记本、没有流程、没有复核的办公室，他一样干不成事——因为没人把这份工作搭起来。 这句话的形状值得注意：它其实是一份岗位说明书。七层里除了第一层，其余六层在做的事，都是公司给一个真实员工配的东西：入职文档、系统权限、笔记本、工作流、复核、最终签字权。所以这七层的顺序不能随便换——它是从招聘到上岗的顺序。 支撑它的两句外部引用也标得清楚：Anthropic 2025 年 6 月那句「最后一公里往往变成整段旅程」，以及 2025 年 9 月给 agent 的定义「LLM 自主地在循环里使用工具」。后者顺带划出一条边界：只回答一次问题的，不叫 agent。 二、七层，以及每层坏掉时的样子# 轻点放大 层 一句话职责 坏掉时的症状 最小可用做法 1 模型 读、规划、决定下一步 换模型、改提示词——最常见的那个错 先用最强模型打标，再按评测降级；锁死具体版本号，不用别名 2 指令与上下文 它动手之前看到的一切 答得像懂，但和你们的流程无关 拿一份团队真在用的 SOP 改写成系统提示词；稳定规则常驻，任务事实按次加载 3 工具 读数据、做事 能说不能做，或者一动手就越权 每个动作标读/写；优先用现成 MCP；给 agent 自己的受限凭据；输入收窄到 ID、绝对路径、固定日期 4 记忆 上下文窗口之外留下来的东西 一轮聊长就退化，上周的结论全丢 MEMORY.md + 只给它这一个文件写权限；长会话前压缩；每周删过期笔记 5 循环与编排 行动、看结果、再决定、停 跑不完、跑飞了、不知道哪一步坏的 把退出条件写进指令；代码里给 max_turns；开 tracing；周期性工作交给 cron 6 评测与护栏 判断它好不好，并在不好时拦住 分数对不上，或者一句提示词就能删掉生产库 20 条真实任务做评测集 + LLM 裁判；暂存库/测试账号/只读密钥；读私密数据 + 读不可信输入的工作流，对外发送必须有人把关 7 人的签核 最后一按 一封没人批准过的客户邮件发出去了 风险分三档；高风险动作走审批卡；记录谁批的 这张表里最容易被忽略的是第三层的输入约束。原文引的 Anthropic 那条判断很硬：「如果一个人类工程师都没法断定某个场景该用哪个工具，就不能指望 agent 做得更好。」以及他们做编码 agent 时的实话——花在优化工具上的时间比优化整体提示词还多。https://icorer.com/icorer_blog/posts/ai/recall-company-brain/Thu, 05 Nov 2026 22:40:00 +0800https://icorer.com/icorer_blog/posts/ai/recall-company-brain/一句话　它把「记住」做成了检索契约：上游只存原文、永不改写，索引与沙箱全是可重建的投影；服务器对召回负责，精确与引用交回给调用它的那台前沿模型。 材料是作者那篇长文，加上开源的 skill 仓库（Apache 之外的部分没开源，MIT，13 个 skill）。文中数字分两类：作者实测的，和我在仓库里数的，各自标注。 一、四代：每一代都被上一代的故障推着走# 轻点放大 阶段 形态 触发的故障 关键数字 4 月 一段 SKILL.md，告诉 agent 转录在哪（~/.claude/projects 下每会话一个 JSONL）、怎么 grep 全靠 agent 即兴，慢且不稳定 只有一份文件 5–6 月 三个脚本：find_sessions.py、extract_user_prompts.py、dump_turn_context.py 每次搜索读全盘，且读不了 Codex 7 月已 5,000+ 份、约 5 GB 7 月 一个 recall.py：SQLite 全文索引 + 实体表（PR 号、文件路径、job id），两种 harness 都读 单机、单人的上限 57 题冻结集上 top-5 从 23% → 63%，搜索 15.7s → 0.16s 8 月起 服务：collector → ingest → 存储 → 投影 → 沙箱，外挂四个 MCP 工具 需要跨机器、跨人 见下文 脚本写出来之后，agent 仍然大约每用一次脚本，就手动 grep 九次。工具没被采纳，不是因为不好用，而是因为它比「直接翻文件」还慢。https://icorer.com/icorer_blog/posts/ai/deepseek-dsec-sandbox-platform/Thu, 05 Nov 2026 15:28:40 +0800https://icorer.com/icorer_blog/posts/ai/deepseek-dsec-sandbox-platform/一句话　这篇报告真正的贡献不是「又造了一个沙箱」，而是先把 agent 训练的沙箱负载量出来：请求按万级成批到达、CPU 只用掉申请的 5%、状态要留十几分钟到几小时、镜像几乎不复用。四个数字同时成立，平台就只能长成弹性执行平台，而不是一个容器运行时。 这篇文章读了什么、没读什么：材料只有 arXiv 上的 2609.22978v1（31 页，2026-09-19 投到 cs.DC，DeepSeek-AI 与清华，作者里有一位实习期博士生）。我没有集群、没有源码、也没有和作者聊过，所以下面全部是论文阅读笔记：数字都标了出自哪一节，凡是我自己的推断都写成「我的判断」，论文没给的我也直接说没给。没有复现，没有实测，也没有替作者做背书。 一、问题：什么时候「沙箱」会变成基础设施（§1）# §1 的推理链很短，但每一段都在收窄问题。 第一段先把 agent 的定义摆出来：模型不是给一段文本，而是和环境交互——读仓库、调工具、跑命令、看失败、改文件，computer-use 任务里还要操作浏览器和桌面。它靠反馈迭代直到任务完成。 第二段把这条链拆成流水线：环境与数据构造 → RL rollout → reward → 策略更新 → 定期评测。其中 rollout 和评测对沙箱压力最大，因为量大、并发高、还和训练循环耦合。第三段补上业界已经在做的事：异步 rollout 把「生成」和「策略优化」流水起来，用持续补充样本的方式压长尾。代价是同时有大量有状态的沙箱在飞，还会被策略更新或调度抢占打断。 第四段是全篇的题眼：每个 rollout 都要现搭一个任务专属环境，包含仓库、依赖、服务、评测脚本和 harness；这个环境要「足够像一台真机器」，能跑没改过的软件栈、包管理器、构建工具、浏览器、模拟器。「像真机器」这句话定了整个平台的成本结构——它排除了函数级的轻量抽象。 然后是七条负载属性，我按「对设计的影响」重排了一下： 属性 论文给的数字 它逼出的设计 成批到达 单任务最多 32K 个沙箱 调度、创建、镜像分发都不能有中心瓶颈 高密度 单节点 800 microVM / 3,200 容器 必须能安全超卖，还要管住干扰 有状态、长寿 p50 17 分钟，p99 超 3 小时（§4） 内存共享与回收变成硬需求 异构 OJ、SWE、安全、computer-use、Android 单一抽象不够，要多种后端 环境多样、复用低 eager pull 慢 1.https://icorer.com/icorer_blog/posts/ai/open-responses/Thu, 05 Nov 2026 08:20:00 +0800https://icorer.com/icorer_blog/posts/ai/open-responses/一句话　它把「消息」换成双向的条目、把流式换成状态机事件、把扩展做成有名字的旁路；于是端点地址和模型名从代码分支变成配置，而代价从适配器转移到了每个字段的语义细节上。 材料来自三处，都读过：规范全文（含 2026-01-15 与 2026-04-24 两个版本）、它的 TypeSpec schema 与仓库、以及 Databricks 与 Vercel 两个已上线实现的文档。数字分两类标注：仓库里数的，和 GitHub API 给的。 一、它规定的到底是什么# 一句话：以 OpenAI 的 Responses API 为底，定义 /v1/responses 这类端点上收发的请求与响应格式。规范自己划的范围很克制——只到 API 层，不碰模型，也不需要重新训练。 它真正定义的是三样东西，而不是一堆 JSON 字段： 零件 规范怎么说 为什么这么定 条目（Items） 上下文的最小单位，双向：既能作为输入给模型，也能作为输出返回 一次推理产出的是「若干个原子事件」，不是一段字符串 语义事件 流式不是文本增量，而是一系列有意义的状态迁移 客户端要能重建结构，而不是拼字符串 扩展 任何实现者可以做真超集；新类型必须带自己的 slug 前缀 供应商要有推出自研功能的空间，又不能互相撞车 轻点放大 它对「合规」的定义也写在里面：直接实现本规范，或者是它的一个真超集，都算合规。这句话很关键——它允许实现者往前加东西，只禁止把标准字段的含义改掉。 二、三个零件：条目、事件、状态机# 轻点放大 条目有四个性质，每一条都在解决具体问题： 多态：靠 type 判别。message 与 function_call 形状不同，客户端按类型分派，不再猜。 状态机：in_progress / incomplete / completed。有一条硬规矩——如果某个条目以 incomplete 结束，它必须是最后一个条目，且整个响应也必须是 incomplete。这就杜绝了「半截话后面又接了一句」的歧义。 可流式：第一个事件必须是 response.output_item.added，此时能给的字段都要给（消息至少给 role，函数调用至少给 name），其余字段用零值占位。这样客户端可以先把骨架画出来，再往里填。 可扩展：非标准条目必须以实现者 slug 打头，比如 openai:web_search_call。 内容还做了一次不对称切分：UserContent 与 ModelContent 是两个顶层联合类型。用户输入可以是文本、图片、音频等多种模态，模型输出在基础协议里只保证文本。这个不对称是有意为之——它让供应商以后加 output_image 之类的东西时，不用把用户那一侧也跟着泛化。https://icorer.com/icorer_blog/posts/ai/ankole-agent-os/Wed, 04 Nov 2026 21:30:00 +0800https://icorer.com/icorer_blog/posts/ai/ankole-agent-os/一句话　把单机 harness 套上聊天框，只搬走了界面那一层；真正的差别在五件事——谁在说话、它记得什么、崩了之后活儿还在不在、它在哪台机器上动手、回复到底送没送到。 先说清楚这篇的材料边界：那篇文章的正文在 X 上要登录才能读，我拿到的只有它自己给出的主张和开头一段。所以下面不复述文章结构，而是把这个主张当成一道题来做——技术细节核对的是 Apache-2.0 的仓库（浅克隆，5,890 个文件）和它随仓库发的文档，包括一份 170 行的《取舍与已知限制》。数字分两类：官方文档写的，和我自己在克隆里数出来的，各自标注。 一、主张先摆出来# 原文的说法是：把聊天界面架在一个单用户 harness 上，或者往群里扔一个 bot，都不叫 Agent OS；把它放进三十人的公司，横跨运营、财务、法务，几周就会碎。 这句话方向是对的。把它拆成五处，每一处都有具体的失效方式。 轻点放大 问题 聊天框 + 单机 harness 团队 Agent OS 的答案 谁在说话 规矩写在系统提示词里 Principal + 运行时 AuthZ 它记得什么 每次从零，检索聊天记录 结构化世界模型，按权限交集召回 进程死了 这一轮工作消失 PostgreSQL 台账，从已提交处续跑 在哪动手 你自己的电脑 每 Agent 一台独立容器 回复送到没 发出去就算完 Delivery 意图，平台确认后再提交 二、谁在说话：权限不是提示词# Ankole 把所有人、Agent、内部服务统一成 (tenant_id, uid) 的 Principal，权限在控制面运行时求值：主体、权限组、Drive 的 ACL 锚点、动作，加上 CEL 条件，一起算。文档里有一句话值得抄下来——访问控制「永远不由提示词约定来执行」。 这条区分落到两种 Agent 上，差别很具体。Personal Assistant 与人一对一绑定，借所有者的共享权限，但保留自己的运行时身份，审计线上看得见是谁做的手脚。AI Colleague 用自己的授权，当它要做超出自身写权限的事（改一个受保护的知识对象），必须发一张 propose_action_card 等人批。群聊里 Agent 的广播回复不会唤醒其他 Agent，要协作就走 send_to_agent 开一条隔离的 peer 会话。https://icorer.com/icorer_blog/posts/ai/auto-ontology/Wed, 04 Nov 2026 20:41:07 +0800https://icorer.com/icorer_blog/posts/ai/auto-ontology/一句话：Auto-Ontology 把本体工程里最贵的那一个月自动化了——它读你的元数据和查询历史，编译出一张业务本体，再用 9 个只读工具交给 agent。但它交出来的是草稿：认证在这套代码里是展示用的徽章，不是查询路径上的闸门。 中文配音版（男声），2 分 04 秒。中英两版内容一致，另有英文配音版。 NVIDIA 在 2026 年 10 月 21 日的 GTC Berlin 上把它作为 Agent Knowledge Foundation 的一部分宣布，11 月 1 日以 Apache-2.0 开源。我读的是 caced11 这个提交（11 月 4 日克隆）的完整后端源码，下面是能逐条对回代码的判断。 一、一次不会报错的错# 一个 agent 能写出跑得通的 SQL，这件事又容易又危险：一条跑通、返回一个「看似合理却错误」数字的查询，不会报错。 最典型的现场是这张表。 轻点放大 财务有三个列都能叫 revenue；销售说的 bookings 和财务说的 revenue 是两回事；一个一对多 join 会让总数静默翻倍，而 SQL 完全合法。传统 text-to-SQL 研究默认难题是「生成语法正确的 SQL」，于是堆模型能力。Auto-Ontology 的判断相反：语法正确不等于语义正确，真正缺的是那层告诉 agent「数据在哪、什么意思、能不能用、怎么用、从哪来、什么相似」的上下文。 这层东西过去只活在数据工程师和业务人员脑子里。它的工作量集中在第一次交付——梳理来源表、定义对象关联、审核指标口径。这也是为什么大部分语义层项目死在第一周：平台装好了，然后没人能说清六个 revenue 定义里哪个是真的。 二、它站在哪条脉络上# 「用本体给数据加一层语义，再把查询翻译回去」不是新想法，但谁来写这层本体变过两次。 轻点放大 路线 本体/口径由谁写 后果 OBDA（本体驱动数据访问） 知识工程师人工建模，一条条映射 表达力强、推理可证；成本让它在企业里长期停在 PoC 语义层（dbt / Cube / LookML） 分析工程师写 YAML，人审 口径可信；从空白页到第一版仍要几周到几个月 LLM 起草 + 人审 模型给草稿，人签认证 第一天就有可审的东西；草稿与权威的界线必须由使用方自己划 学术上这两条线都有三十年积累。OBDA 的三层结构（数据源 / 映射 / 本体）与 Auto-Ontology 的 catalog / semantic FK / terms 几乎同构，区别只在于本体不再是人工建的。近三年这条线被 LLM 重写了一遍：《Towards Agentic Schema Refinement》（arXiv 2412.https://icorer.com/icorer_blog/posts/ai/one-person-creative-team/Wed, 04 Nov 2026 07:20:00 +0800https://icorer.com/icorer_blog/posts/ai/one-person-creative-team/一句话　那封信能带走的东西是岗位拆分，把创意总监的活拆成品牌策略、内容策略、写作与运营三件事。价码、工具推荐与那串增长数字属于它的销售面。 Dan Koe 十一月发了一封长信，主张最有价值的技能一直是抓住注意力。他给了三个数字撑起紧迫感，给了三个岗位撑起方法论，最后落到一个具体做法上，先免费替目标客户做十条帖子，再把成品递过去。 这封信是一封销售信。作者是 Eden 的创始人，信里同时推了 Eden 与一个 49 美元的写作工作坊。把这一层先摆出来，不影响它中间那段岗位拆分的价值。 一、三个数字，三条都不是普查# 先把信里的加速度拆开。三条数据都真实存在，口径各不相同。 轻点放大 高盛研究部 2023 年 4 月那篇说的是创作者经济的总可寻址市场，从 2500 亿美元走向 2027 年的约 4800 亿。这是该机构自己的模型估算，不是一次市场普查。 IAB 的创作者广告投放报告给的是美国品牌支出，2021 年 139 亿，2024 年 295 亿，2025 年 371 亿，2026 年的 439 亿是预测。信里把它写成五年三倍，两端数字都没错，只是终点还没发生。 第三条来自 WPP Media 2025 年中的全球广告预测，说创作者平台的广告收入这年首次超过传统媒体，创作者一侧大约 1850 亿美元。同样是预测值。 指标 值 来源 口径 创作者经济总量 2500 亿 → 4800 亿美元 高盛研究部，2023-04 预测 美国品牌创作者投放 139 亿（2021）→ 439 亿（2026） IAB 实测 + 预测 创作者广告收入 约 1850 亿美元（2025） WPP Media 预测 这三条放在一起能说明的只有一件事，注意力确实在往社交平台集中，规模也够大；两条是预测、一条是实测加预测，没有一条在讲个人成功率的分布。https://icorer.com/icorer_blog/posts/ai/cognitive-surrender/Wed, 04 Nov 2026 06:54:07 +0800https://icorer.com/icorer_blog/posts/ai/cognitive-surrender/一句话　把活交出去没问题，把判断权交出去是另一件事。这条下坡分成三档，每一档都像上一档的合理延伸。 中文配音版，2 分 33 秒。英文版 2 分 41 秒，同样的镜头、同样的数字。 Addy Osmani 十一月在 X 上发了一篇长文，讲 agent 时代怎么保住批判性思考。他先把立场摆清楚，自己每天都在用，一天并行开好几个会话，写这篇不是劝人少用工具。 文章的主线在另一件事上。工具越好用，人越容易停止判断，而这件事恰好没有声音。 下面把它拆成一条能画出来的斜坡，补两组可以查的数字，最后说清楚哪一步他自己也没说满。 一、判断原来长在留白里# 过去的判断发生在提问和回答之间。你查资料、自己想一遍、再回来核对，中间这段时间里答案是你自己拼出来的。 现在这段时间按秒算。你读完一段写得很顺的回答，顺手就点了通过。 轻点放大 Osmani 用一句话点破这中间的差别。很多输出会写得不错，而且大体正确，但它们不要求你再看第二眼。 二、下坡分三档# 他排出一条频谱，我更愿意画成一条斜坡。 轻点放大 最上面一档叫委托，活递出去，结论还归你，你会核对一眼。中间一档叫转交，它的输出成了你的输入，你不再怀疑。最下面一档叫投降，它的答案就是你的答案，你连该查什么都想不起来。 认知投降这个词是沃顿的 Steven Shaw 和 Gideon Nave 在 2026 年 1 月提出的，出自他们那篇挂出来的预印本。两个人把双系统理论往下推了一层，加了 System 3，指的是发生在脑外的思考。 滑坡很少被人当场发现，因为每一步都是上一步的合理延伸。你上一份答案读完了，这一份就只扫骨架；再下一份，你连骨架都没看。等到有人在会上问起某一行，你发现自己讲不出来。 这份代价有个名字，叫认知债。代码看起来干净，测试是绿的，团队的心理模型在悄悄变薄。 三、两组实验，方向相反# Osmani 那篇偏经验，这里补两处可以查的数字。 第一组来自沃顿。三次预注册实验，一千三百七十二个人，九千五百九十三次 trial，被试在认知反射测验上作答，同时可以随时去问一个 AI。研究者用隐藏的种子提示随机决定模型答对还是答错。 结果是一个对称的摆动：模型答对时，准确率比不用模型高二十五个百分点；模型答错时，低十五个百分点。 轻点放大 扎人的地方在信心。出错之后，被试的自信还在涨。信心像是从模型那里借来的，而模型对什么事都很笃定。 第二组来自 Anthropic 自己对技能形成做的对照实验。研究者让工程师用 AI 辅助学一个陌生的 Python 库，再考一遍理解。 轻点放大 用 AI 写代码的那一组，理解测验比手写组低百分之十七，27 分制上低 4.15 分。把 AI 当作提问对象、追着问为什么要这么写的那一组，没有掉。https://icorer.com/icorer_blog/posts/ai/jevact-decision-gate/Tue, 03 Nov 2026 12:27:14 +0800https://icorer.com/icorer_blog/posts/ai/jevact-decision-gate/Agent 的动作在被执行之前，应该有一道能查、能算、能打回的门。JevAct 的做法是把这道门拆成两半。代码算工具记录能确定的事实，决策模型只回答“对话里到底说了什么”，再用一条布尔规则把两者合起来。它在 τ²-Telecom 上让八个 agent 全部变好，也清楚地暴露了自己的边界。 中文配音版，2 分 41 秒。中文与英文两版内容一致。 原文是《Think Before You Act》（IBM SIL，副标题 Decision Gate for LLM Agents），arXiv 编号 2610.38620，全文 18 页，点开就能读 arXiv 页面 ，也可以直接看 PDF 。这篇是我读完全文之后写的，下面的数字、阈值和局限都能在原文里逐条对回去。 一、提案即执行# ReAct 之类的 agent 循环有一个默认动作，模型说什么，harness 就执行什么。这在“回答错了还能下一轮改”的场景里问题不大，但有三类动作是不可逆的（§1）。 不可逆的动作 出错的代价 写调用（预订、取消、改设置） 改了数据库状态，有的改不回来 交班（转人工、告诉用户“没办法了”） agent 的尝试结束，用户被推给下一个人 不该发生的写（用户没要求） 越权，比答错更严重 现有方法各自解决一部分（§2），ReAct 交错推理与动作；Self-Refine、Reflexion 在事后批评、下一轮改；GuardAgent、AgentSpec、ShieldAgent、CUGA、ToolSafe、PolicyGuard、ToolFence 这一类做运行期策略约束（§2.2）；LLM-as-a-judge 让另一个大模型来评审（§2.3）。但“在这一条动作执行前，用一条可执行的规则判断它对不对”仍然是缺口，生成式的评审会给出解释，解释还要再被解析成“放行/拦截”；而用前沿模型逐条评审，成本又高。 论文的立场很明确，把这道门做成概率阈值化 + 可执行检查，而不是再找一个更大的模型来“讲道理”。 二、两种证据，各管一半# 轻点放大 图 1 agent 仍然负责提议，门只负责决定“执行还是打回”。 JevAct 是一条跑在 ReAct 循环外面的 harness。它不选动作，只做验证。关键在于把“这个动作对不对”拆成两类问题。 工具记录能确定的事实。预订创建于几小时前、免费托运额度是多少、这单是不是已经飞过一段、金额有没有超。这些交给代码算，因为算术与日期比较是决策模型最不擅长的。 只能从对话读出的事。用户到底要求了什么、有没有明确确认、某个排障步骤是不是试过。这些交给决策模型用是非题回答。 两条证据最后由一条布尔规则合成结论。这一步是论文的设计主张，确定性的部分不要交给概率模型，概率的部分不要硬塞进代码。 三、四个组件# 3.1 决策环的四个阶段# 每一步四阶段。https://icorer.com/icorer_blog/posts/ai/super-agent-design/Mon, 02 Nov 2026 06:30:00 +0800https://icorer.com/icorer_blog/posts/ai/super-agent-design/一句话：这篇长文里最值钱的不是那五个模块——模块会随部署形态变；最值钱的是一句判断：会话应该是系统的实现细节，不是用户的认知负担。下面把它拆开，再用它自己开源的 dsh-superagent-prototype 对一遍账。 原文 2026 年 10 月 31 日发布，开头就写明：这是架构思路探讨，不是产品功能说明。同日团队把原型放上 GitHub，MIT 协议，README 里同样写着「研究代码，不等于内部版本」。所以有两种读法：先当论文读，再当 PRD 读——两种读法给出的结论不一样，差别本身才是有用的部分。 一、问题：多任务的上限，是人的注意力# 作者的观察很克制，也很扎人： 单任务的上限取决于模型能力，多任务的上限取决于人的注意力。据我们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。 这句话没有附测量方法，但跑过三个 agent 并行的人大多会点头。原因不在人懒，而在现有 agent 把两件事焊死在了同一个对象上： Session 同时承担 后果 模型上下文的容器 为了「连续」不敢换会话，为了「干净」又必须换 用户的项目管理单位 于是「关掉会话」等于「丢掉项目」 于是有了三条结构性限制：单会话同步阻塞、多任务上下文互相污染、设备一休眠就停。加 CLI、加 MCP、加连接器都改不了这三条——会话被当成了系统的边界。 二、它提了什么：五个模块# 原文主张四个特征——连续、高效、主动、持久——并且认为没有任何一个 ReAct Loop 能同时给出来。于是它们各自落到不同模块上： 特征 靠什么 掉了会怎样 连续 双层架构，所有信道汇到 Router 你得自己记住哪个会话里有哪句话 高效 上下文隔离的并发 Worker 一次只能推进一件事 主动 Trigger + 两级过滤 + 投机执行 永远等指令，等于一个更贵的命令行 持久 存算分离 + 端侧 daemon + Watchdog 电脑一合盖，活就停了 轻点放大 这套设计没有提出新理论，作者自己也这么说。它做的是把计算机系统里一串经典手法——两级调度、快慢路径、把上下文窗口当 cache、投机执行、存算分离、外部看门狗——搬到 agent 系统上。所以读的时候该问的是每个类比在哪里成立、在哪里失效。https://icorer.com/icorer_blog/posts/ai/trusted-mcp-runtime-architecture/Sun, 01 Nov 2026 12:00:00 +0800https://icorer.com/icorer_blog/posts/ai/trusted-mcp-runtime-architecture/一句话：把工具当成可寻址的产物、放进沙箱执行、用身份兜底，MCP 才配得上「可信」两个字。这是架构；后半篇是它的实现。 一、问题：Agent 的工具，是黑盒# Agent 的能力边界不是模型，而是它能调到的工具。可今天的工具是黑盒：第三方代码、一工具一容器、集中托管。 后果 现场表现 代价 来源不可验证 不知道跑的是哪一段字节，也不知道有没有被改过 不敢把敏感数据交给它 架构不可移植 x86 / ARM / RISC-V 各编一份二进制 工具到不了边缘 负载不可扩展 一容器一工具，冷启动 527–1119 ms、常驻 69–94 MB 小设备挂不起几个 工具这一层的问题落在信任上：你既不能核对它，也不能搬动它，还不能按需放它出去。 二、行业研究走到哪一步了# 近两年围绕「MCP + WebAssembly」的研究，把这件事拆得比较清楚了。归纳成三个缺口和一组对策（数据与设计主张来自公开论文，实测环境为 Intel NUC）： 缺口一：协议只有功能元数据。 MCP 的 tool schema 描述「叫什么、要什么参数、返回什么」，但没有「跑多久、吃不吃 CPU、数据在哪、能不能出设备」。调度器看不见执行需求，只能猜。 缺口二：冷启动与指令集把边缘挡在门外。 容器化 MCP server 冷启动 527–1119 ms、常驻 69–94 MB；原生二进制要为每种 ISA 单独构建。数据集里 22.3% 的 server 只支持本地 stdio、77.7% 只支持远程 HTTP、0% 两者都支持——传输方式在编译期就被写死。 缺口三：现有 SDK 绑死系统原语。 它们建在 thread / signal / socket 上，而 WASI 里这些都没有；于是 WASM 侧缺一个原生传输层，只能靠 sidecar 代理，反而把 WASM 省下的开销还了回去。