OpenAI 应用基础设施 VP Venkataramani 2026 年 3 月的原话是 “there are easily 1,000x engineers now”；METR 2025 年 7 月的随机对照实验测出来，AI 工具让 16 位资深开源维护者的任务完成时间增加了 19%。同一个行业，同一个年份，两个相差 50 倍数量级的说法都在流通。

这两个数字谁对？都不对，因为它们根本不在同一层。1000x 是修辞，-19% 是一次实验在特定人群上的测量。真正的问题不是"信谁"，而是这行当的概念体系被营销话术搅成了一锅粥：AUI 被当成正式标准、Multi-Agent 和 Multi-Harness 混用、MCP 的过时教程满天飞。这篇文章做一次分层大扫除——每个术语给出英文全称、定义出处、和相邻概念的分界线，所有事实标注资料时间（2026-09-22 核实），俗语标俗语，标准标标准。

一、100x/1000x：一个从未被测量过的数字

先讲这个词的来历，因为它的来历就是它的问题。

“10x programmer"的源头是 1968 年 Sackman、Erickson 和 Grant 发表在 CACM 的实验。原始研究比较的是批处理和联机终端两种编程方式的差异，不是程序员个人能力的差异；传播中被引用的 28:1 是最快者与最慢者的极差统计，当年同一期 CACM 就有批评指出测量不确定性极大，差异很大部分来自所用技术而非人（Prechelt 1999 年的剖析）。“10x engineer"作为病毒说法则源于 2019 年 7 月 Accel 投资人 Shekhar Kirani 的一条推文，内容是"用 IDE、讨厌开会、深夜写代码”，是投资人修辞。2025 年 Surge AI CEO Edwin Chen 把 2-3x 编码速度 × 2-3x 更努力 × 2-3x 少杂事连乘出 100x；2026 年 3 月 OpenAI 的 Venkataramani 再推到 1000x。整条传播链上，没有任何一环给出过可操作的测量定义。

被真正测量过的数字长什么样：

表格里有两行值得停下来看。METR 那行的刺点是：开发者事前预测 AI 会提速 24%，事后仍自估提速 20%，实测是 -19%——自我报告和实测方向相反，这一条就该让所有"我感觉快了很多"的数据降权。METR 2026 年 2 月的后续实验还发现更深的问题：57 人实验因选择偏差整体失效，最乐观 AI 的人拒绝参加无 AI 条件、30-50% 的参与者承认跳过不想做的任务。MIT 那行则是目前规模最大的严格实验，结论是 +26%，即 1.26x。

为什么从 1.26x 到 100x 中间隔着的是工程现实，不是工具进步？因为倍数主张几乎都停在第一层，交付发生在第四层：

1. 代码生成量：token 和行数。GitClear 对 2.11 亿行变更的分析显示，复制粘贴代码占比从 8.3%（2021）涨到 12.3%（2024），重构类变更从约 25% 跌到不足 10%——生成量增长和维护性恶化同步发生。
2. 任务吞吐：PR 数、任务数。上表第二层，结果从 -19% 到 +55.8% 大幅摆动，完全取决于任务难度和人群经验（新手获益大，老手在自己最熟的仓库上反而慢）。
3. 验证后交付量：合并且不回滚的代码。没有任何研究直接测过这层，只有代理指标——Uplevel 的 bug +41%、Stack Overflow 2025 调查里 66% 的开发者说"AI 方案几乎对但不完全对"导致花更多时间修、GitClear 的 churn 数据。
4. 业务价值：收入、用户、留存。零测量。

Simon Willison 2025 年 8 月的自评是这领域少见的诚实样本：“LLMs make me 2-5x more productive on the parts of my job which involve typing code into a computer”——2-5 倍，限定在打代码那一部分。截至 2026-09，所有经过同行评审或可复核的实测增益没有超过约 2.5x 的；1000x 没有任何实证支撑，它的实际功能是把"工程师"重新定义为"指挥大量 agent 的编排者”，然后对编排者谈杠杆——但 OpenAI 自己同场访谈也承认，code review、安全审查和 CI/CD 扩容这些验证环节没变快。

作者建议的测量框架（这是本文自建，不是行业标准）：谈倍数先钉死四个钉子——基线是谁、测哪一层的产出、错误率和返工怎么计入、验证成本算不算分母。任何一个答不上来的倍数，当作营销处理。

二、界面层：GUI、CLI、TUI、Web UI、AUI、VUI

这一组是最容易讲清楚也最容易被讲混的，先把分界线画出来：

前五个有稳定通行定义，维基百科级别的锚点就够。两个常见错误：TUI 不是 CLI 的子类——CLI 是逐行的输入输出流，TUI 接管整个屏幕画窗口和菜单，维基百科在 TUI 词条明确标注 “Not to be confused with Command-line interface”；htop 是 TUI，ps 是 CLI。Web UI 不是独立于 GUI 的第四种东西——严格说是"用 Web 技术栈实现、经浏览器渲染的 GUI"，边界锚定在浏览器+HTTP 的分发机制上。

AUI 是这组里唯一没有正式标准的缩写，至少有四种并行用法：AI 圈 2025 年以来指 Agentic UI / Agent User Interface（让 agent 在应用内执行任务的界面层，Salesforce、各家设计工作室的用法）；HCI 学术语境指 Adaptive User Interface（自适应界面）；无障碍领域指 Audio/Audible User Interface（音频界面）；还有学术论文把它展开成 Agent-friendly UI（为 agent 而非人眼优化的界面，NUS Show Lab 的 AUI-Gym 基准）。Anthropic 和 OpenAI 的官方文本从未使用 “AUI”：Anthropic《Building Effective Agents》（2024-12）用的词是 ACI（agent-computer interface，代理-计算机接口）——给 agent 调用的工具接口要像 HCI 一样认真设计；MCP 官方生态用的是 “agentic app” 和 MCP Apps（SEP-1865 扩展提案，2025-11 发布，OpenAI 与 Anthropic 员工共同署名，让 MCP server 向宿主应用提供可交互 UI）。另一个相邻物是 AG-UI 协议（CopilotKit 出身的开源事件协议）。中文写作建议：首次出现必须展开全称，单独写 “AUI” 三个字母等于没写。

为什么 Agent 工程偏爱文本界面？ 这个直觉有实证支撑。arXiv 2609.11999《Is Bash All You Need?》在企业基准上对比五种工具接口形态，发现只用 bash 比类型化工具得分高 21.8-24.5 个百分点，还省 19-72% 的 token（注意：单一研究结论，论文自己也指出安全合规场景需要固定工具目录）。结构性理由从 CLI 的定义就能推出来：文本输出可 grep、可管道、可结构化解析、可完整落日志审计；GUI 对 agent 意味着像素级识别和不组合的点击流——维基百科 GUI 词条原话，“icons and dialog boxes are usually harder for users to script”。这也是为什么 Claude Code、Codex CLI、Gemini CLI、Aider、OpenCode 五个头部 coding agent 全部长在终端里。

三、接口层：API、SDK、MCP

三个词管三件事：API 是服务本身，SDK 是 API 的工程化封装，MCP 是工具连接的协议标准。

API（Application Programming Interface），LLM 语境下指模型服务商暴露的 HTTP 接口。以 Anthropic Messages API 为例：POST /v1/messages，必填 model、max_tokens、messages（user/assistant 交替轮次），可选 system、tools、stream。两个对后文重要的细节：API 是无状态的，多轮对话每轮都要重发完整历史（成本模型由此而来，见第六节）；工具调用是协议级标准化的——客户端发 tools 参数，模型返回 stop_reason: "tool_use" 的 tool_use 内容块，客户端执行后把带 tool_use_id 的 tool_result 块放回下一条消息，循环直到 end_turn。

**SDK（Software Development Kit）**是对 API 的类型化便利层，不提供 API 之外的新能力。以 anthropic-sdk-python（v1.7.0，2026-09-18）为例：请求参数是 TypedDict、响应是 Pydantic 模型；自动重试默认 2 次、指数退避，覆盖 429/5xx；流式助手 messages.stream()；请求前 token 计数；类型化异常。判断一个东西是 API 还是 SDK 的方法：模型能做什么由 API 和模型决定，SDK 升级是工程接口变化而非能力变化。

MCP（Model Context Protocol），Anthropic 2024 年 11 月开源、2025 年 12 月捐赠给 Linux Foundation 旗下 Agentic AI Foundation（AAIF）的工具连接协议。截至 2026-09 的事实基线（这些必须带版本号，见下文为什么）：

• 基于 JSON-RPC 2.0；架构是 host-client-server：一个 host 应用管理多个 client，每个 client 与一个 server 一对一通信。
• Server 通过三类原语暴露能力：tools、resources、prompts。注意术语精度：hosts/clients/servers 是架构角色，tools/resources/prompts 是原语，混写即错。
• 传输两种：stdio（本地子进程）和 Streamable HTTP（远程端点）。旧 HTTP+SSE 传输在 2025-03-26 修订中被取代，现处 deprecated 状态。
• 最新版本是 2026-07-28，一次结构性大改：协议转为无状态（移除 initialize 握手和会话头），新增多轮往返请求（MRTR），列表结果可缓存，OAuth 硬化，roots/sampling 进入废弃流程。
• OpenAI（2025-03）与 Google（2025-04）先后宣布采纳；AAIF 2026-09 口径：Tier 1 SDK 月下载接近 5 亿，已发布 MCP server 超 1 万个。

MCP 和 function calling 不是竞争关系。MCP 管工具的发现、连接和传输；模型是否调用、怎么填参，靠的是各家模型的 tool calling 能力——MCP 官方文档对 tools 的定义是 “model-controlled”。一个不支持工具调用的模型接上 MCP server 也用不了它。社区那句"MCP 把 M×N 集成问题降为 M+N"是通行表述，规范原文支持方向但没用这个量化说法。

为什么写 MCP 必须带版本日期：MCP 从 2024-11-05 初版至今经历了 2025-03-26、2025-06-18、2025-11-25、2026-07-28 数次修订，间隔不固定但每次都是行为级变更。2025 年的 MCP 教程里写的 initialize 握手、Mcp-Session-Id、有状态会话，在最新规范里已经不存在——引用二手资料几乎必然过时，本文这部分事实直接取自 GitHub 仓库 main 分支 2026-07-28 规范原文。

四、执行层：Agent、Harness、Multi-Agent、Multi-Harness、Multi-Vendor

这一组是重灾区，因为 Harness 没有官方标准定义，各家用法相近但不是同一份规范。能做的是把各家的原话并列，然后说清哪些是词义滑移。

Agent。业界被引用最多的定义锚点是 Anthropic《Building Effective Agents》（2024-12-19）的二分：Workflows 是"LLM 与工具通过预定义代码路径编排的系统"，Agents 是"LLM 动态指挥自己的流程与工具使用"的系统。一句话版：agent 通常就是 LLM 在循环中基于环境反馈使用工具。Simon Willison 的版本是 “LLMs calling tools in a loop to achieve a goal”，他同时批评 OpenAI 的宽泛定义（“a system that can do work independently on behalf of the user”）搅浑水。注意：连 agent 的定义都没有跨厂商标准，所以"XX 是不是真 agent"的争论基本是定义之争。

Harness。这个词 2025 下半年才被官方文本高频使用，三个代表性用法：

• LangChain《The Anatomy of an Agent Harness》（2026-03）给的公式最直白："Agent = Model + Harness"、“If you’re not the model, you’re the harness”——harness 是模型之外的一切：系统提示、工具集、MCP、沙箱、编排逻辑、hooks、上下文压缩。
• Anthropic《Effective harnesses for long-running agents》（2025-11）：“The Claude Agent SDK is a powerful, general-purpose agent harness”——系统提示+工具集+上下文管理，让循环跨多个 context window 运行。
• Anthropic 文档对 Claude Code 的定位原文：“Claude Code serves as the agentic harness around Claude: it provides the tools, context management, and execution environment that turn a language model into a capable coding agent.”

有一个词义滑移要警惕：Anthropic 在《A harness for every task》（2026-06）里把"多 agent 的编排层"也称 harness——同一词在"单 agent 执行壳"和"多 agent 编排层"两种粒度上都出现过。写文章时 harness 必须落到具体出处。具体例子好认：Claude Code、Codex CLI（openai/codex，约 125.7k stars，2026-09-21）、Gemini CLI（约 107.1k）、Aider（约 49.1k，provider 无关设计的早期代表）、OpenCode（约 209k，现为 anomalyco 维护）都是 coding agent harness。

然后是三个"Multi"，它们是三个不同的维度，不是同义词（这个三维区分本身是本文整理的框架，不是行业共识定义）：

Multi-Agent 的量化权衡来自 Anthropic《How we built our multi-agent research system》（2025-06）：orchestrator-worker 架构、subagent 各自隔离 context window，代价是多 agent 系统 token 消耗约为普通对话的 15 倍（单 agent 约 4 倍），换来内部研究评测上比单 agent 高 90.2%（都是 Anthropic 自家系统的自测数字，不是普适常数）。适用条件被原文点名：任务高度可并行、信息量超单 context window；“多数编码任务真正可并行的部分比研究类少”——默认堆 agent 数是最常见的误用。

Multi-Harness 的社区实例（2026-09-21 可核实）：wshobson/agents（约 39.8k stars）自述 “Multi-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, Google Antigravity, and Pi”——单一 Markdown 源分发到多个 harness；harness17/cross-agent-harness 用交接文件让 Codex 实现、Claude Code 交叉评审。注意它极易和"multi-agent harness"（单个 harness 内编排多 agent，LangChain 博客的用法）混淆——词序相反，概念不同。

Multi-Vendor 落地的典型基础设施是路由层：LiteLLM（BerriAI，约 59.3k stars，OpenAI 格式统一 100+ provider，带 retry/fallback 和成本追踪）、OpenRouter（跨 provider 负载均衡+自动降级）、claude-code-router（约 37.4k stars，本地网关，把多个 coding agent 经稳定端点路由到自选 provider）。Claude Code 官方文档自己也列了多 vendor 部署路径：Anthropic 直连、Bedrock、Vertex、Foundry，或经 LLM Gateway 统一接入，并建议用环境变量 pin 住第三方部署的模型版本——不 pin 时模型别名解析可能滞后于最新发布。这一层的核心风险就是"行为兼容"，下一节展开。

五、分层关系图

把上面四层叠起来，一个现代 agent 系统的全貌是：

flowchart TB
    U["用户"] --> UI["界面层
GUI / CLI / TUI / Web UI / AUI"]
    UI --> H["Harness（执行系统，无标准定义）
agent loop · 工具集 · 权限 · 上下文管理"]
    H --> SA["Subagents
（各自隔离 context window）"]
    H --> MCP["MCP servers
（工具连接协议，JSON-RPC）"]
    H --> SDK["SDK（便利层）"]
    SDK --> API["API（协议层）"]
    API --> V["Vendor / Provider
Anthropic · OpenAI · Google · DeepSeek …"]
    V --> M["模型"]
    ROUTER["路由层
LiteLLM / OpenRouter / CCR"] -.-> API

读图的三条要点：一，换模型只动最底下一层，换 harness 动的是中间整层——同一模型换 harness 表现差异巨大，因为权限检查、上下文压缩、工具校验这些关键工程都在 harness 层（第六节给实例）。二，MCP server 挂在 harness 上而不是模型上，所以一个 MCP server 可以被多个 harness 复用。三，路由层是可选插入件，它统一协议格式，但统一不了行为（下文）。

六、案例：修一个失败测试的完整循环

这是全文的落地节——拿 Claude Code 官方文档（how-claude-code-works，2026-09-22 核实）的"fix the failing tests"原型场景，看每一层在哪一步干活。

你说一句 “fix the failing tests”，之后发生的事，官方文档给的序列是：

1. Run the test suite to see what’s failing（跑测试看什么挂了）
2. Read the error output（读报错）
3. Search for the relevant source files（搜相关文件）
4. Read those files to understand the code（读代码）
5. Edit the files to fix the issue（改文件）
6. Run the tests again to verify（再跑测试验证）

“Each tool use gives Claude new information that informs the next step. This is the agentic loop in action."——收集上下文、采取行动、验证结果，三阶段循环直到完成。这个平淡的循环里，每一层各干各的活：

界面层（CLI/TUI）：你的输入是一行文本；第 6 步跑测试的输出也是文本——可以被 grep、被截断、被塞回上下文。这就是第二节"agent 偏爱文本界面"的具体形态。

Harness 层：这一步最多。Edit 工具有"先读后改"的三重前置检查——必须先在本会话 Read 过该文件、old_string 必须精确匹配、必须唯一出现，harness 在执行工具前做静态校验而不是靠模型自觉。权限系统分层介入：default 模式下改文件、跑命令、联网都要问你；deny 规则在包括 bypassPermissions 的所有模式都生效。Bash 跑测试的输出如果上万行，PreToolUse hook 可以先 grep 过滤只回填失败行，上下文从数万 token 降到数百。上下文快满时 harness 自动压缩——先清较老的工具输出再做摘要，你的原始请求和关键代码保留，早前的详细指令可能丢失；官方文档还写了失控保护：如果单个工具输出大到每次摘要后上下文立刻重新填满，Claude Code 会在几次尝试后停止压缩并报错，而不是无限循环。

协议层（API）：循环的每一圈是一次完整的 API 请求——Claude Code 每次请求重发整个会话历史，靠 prompt caching 把重复前缀的读取价格降到基准输入的 0.1 倍。模型决定调用工具时返回 tool_use 块，harness 执行后把 tool_result 回填，协议在此是严格标准化的。

Vendor 层：换一个 provider，协议字段可能完全兼容（经路由层归一成 OpenAI 格式），但循环的行为会变——这就是"API 兼容不等于行为兼容”。三个可核实的事故样本：vLLM 的 issue #57726，配置 reasoning parser 后结构化输出约束被静默跳过，返回 200 且无警告的非约束补全，调用方无法检测；LiteLLM 的 issue #8313，同一份代码从 Ollama 切到 Azure，工具调用的 arguments 一个是 dict 一个是 string，直接类型崩；SWE-bench Verified 的 bash-only 榜（2026-09-21 检索，同一 mini-SWE-agent 脚手架控制变量）上，模型解题率从 Qwen2.5-Coder-32B 的 9.0% 到 Claude Opus 4.5 的 76.8%（mini-SWE-agent 2.0.0 版结果，脚手架版本本身也影响数字），相差 8 倍以上。协议兼容只是换模型供应商的最低门槛，换完必须跑回归测试。

循环里最容易死在哪一步：官方 best-practices 列的五大用户侧失败模式——厨房水槽会话（无关任务混一个上下文）、反复纠正（纠正两次仍错说明上下文已被失败尝试污染）、超长 CLAUDE.md、信任-验证缺口（生成看起来合理但不处理边界情况的实现）、无限探索（不设边界地读几百个文件）。对 SWE-bench-Verified 150 个失败样本的一项人工分类研究（arXiv:2509.13941，单一预印本）给出根因分布：约 65% 推理缺陷（认知死锁、固守失败策略）、25% 知识缺失、10% 环境摩擦；失败任务平均消耗成功任务 3.5 倍的交互步数，约 25 轮之后收益急剧递减。治理手段官方也给了：给 Claude 一个它能自己跑的检查点——“Claude does the work, runs the check, reads the result, and iterates until the check passes. It’s the difference between a session you watch and one you walk away from.”

七、工程实践清单：六件事的落地做法

可观测性。最小可行集是社区共识（非标准）：结构化事件日志 + tool call 级 trace——OpenAI Agents SDK 默认就采集 LLM 生成、工具调用、handoff 事件；自建常见做法是 append-only JSONL 事件流（run_id、span_id、工具名、参数摘要、结果状态、token 用量、耗时）。要标准化载体的话，OpenTelemetry GenAI 语义约定定义了 gen_ai.usage.input_tokens 等镜像各家计费口径的属性，但截至 2026-09 仍是 Development 状态且刚迁到独立仓库（2026-05），生产采用要接受命名会变。平台选择从 LangSmith（托管）到 Langfuse（MIT、可自托管）都有。

权限。分层防御是官方立场：权限模式（default/acceptEdits/plan/auto/bypassPermissions）+ 逐工具 allow/deny/ask 规则 + OS 级沙箱（macOS Seatbelt / Linux bubblewrap+socat）+ hooks 介入。Claude Code 沙箱文档的原话值得抄进任何 agent 设计文档：“Sandboxing, permission rules, and permission modes are complementary layers”——权限管模型决策，沙箱管模型决策被绕过之后的世界，二者互补。bypassPermissions 官方限定只在容器/VM 里用。

任务状态与恢复。幂等责任放在消费侧是生态共识：OpenAI 的 webhook 指南明确要求用 webhook-id 头做幂等键去重（同投递可能重复）。框架层的落地是 LangGraph 的 checkpointer（同 thread_id 断点恢复）+ store（跨线程）。给 agent 的循环设停止条件（最大迭代数）是《Building Effective Agents》的明文建议。

错误恢复。LLM 输出不可靠的兜底闭环：结构化输出（Anthropic 的 strict tool use / OpenAI 的 Structured Outputs 保证 schema 匹配）+ 错误结构化回传（is_error: true 的 tool_result，模型通常会带修正重试 2-3 次）+ 速率限制遵守 Retry-After 头、无头时带抖动的指数退避。错误消息要写得"有指导性"——说明哪里错、下一步该试什么。

成本统计。缓存计价结构因厂商和模型代际而异：Anthropic 多数模型缓存读为基准输入的 0.1 倍（个别新模型折扣更深）、5 分钟 TTL 写入 1.25x、1 小时 2x；OpenAI GPT-5.6+ 读 0.1x、写 1.25x，更早模型写入不收费且费率各不相同。multi-agent 的 token 放大（约 15x）必须进预算模型。Claude Code 官方企业口径约 $13/开发者/活跃日——这类数字只能当量级参考。

验证。这是把第一层"生成量"兑换成第三层"交付量"的唯一通道，也是 100x 叙事里唯一没变快的环节。工程形态就是第六节那套：可自跑的检查点、独立评审 agent、Stop hook 确定性门、跨 harness 交叉验证（Claude Code 写、Codex 评审正是 Multi-Harness 的正职用法）。

八、风险清单：这套体系会咬人的地方

• 术语漂移：MCP 数月一版且间隔不固定，2026-07-28 是结构性重写；Claude Code 的工具名都在改（Task 在 v2.1.63 改名 Agent）。任何引用不带日期的教程和数字，默认过期。
• 供应商锁定：harness 的上下文工程（系统提示、工具描述、压缩策略）是围绕特定模型行为调的，经路由层换模型后这些隐含假设全部悬空。协议兼容是最低门槛，行为兼容要自己测。
• 复杂度自我增殖：Anthropic 官方建议是"找最简单的可行方案，只在可证明改进产出时才增加复杂度"——先单模型+工具，再 workflow，最后才是多 agent。每加一层 Multi 都有对应的成本：Multi-Agent 是 15x token，Multi-Harness 是编排和上下文交接开销，Multi-Vendor 是回归测试矩阵。
• 上下文是稀缺资源：官方原话，“The context window is the most important resource to manage”，性能随上下文填充而退化。压缩是有损摘要，不是魔法。
• 静默失败：agent 引入的 bug 常被表面化处理掩盖（哥伦比亚 DAPLab 对 15+ 个 vibe-coded 应用的归纳：静默吞错、业务逻辑不匹配、幻觉出假的环境变量而不是向用户要真实值）。vLLM 那个静默跳过约束的 issue 是接口层的同款问题。
• 测量自欺：自估 +20% 实测 -19%（METR）。任何内部"效率调研"不控制选择偏差和自报偏差，结论都会系统性偏乐观。

九、结语：从"调用模型"到"构建执行系统"

把这锅术语粥收干成一段话：界面管人怎么进（GUI/CLI/TUI/Web UI/AUI），接口管程序怎么连（API/SDK/MCP），harness 管 agent 怎么跑（工具、权限、上下文、循环），三个 Multi 管怎么扩（agent 数、执行系统数、供应商数），vendor 管模型从哪来。 层与层之间不通用、不互斥、也不可互相替代——说清了这一点，“AI 工程师"这个词才开始有工程含义。

而 100x/1000x，回到开头那对相差 50 倍数量级的说法：修辞有修辞的用处（愿景确实能募集资源），但工程决策要建立在被测量的数字上。截至 2026-09，那个数字的上界是 1.26x 到 2.5x，条件依赖人群和任务，且验证环节的瓶颈原封未动。差距不在模型不够强，在"生成的代码"和"交付的价值"之间还隔着错误率、返工、review 和信任——这几样，MCP 管不了，harness 也只管得了其中一半。

最后停在 SWE-bench bash-only 榜单的那个数字上：同一个脚手架、同一批任务，只换模型，解题率 9.0% 到 76.8%。模型供应商那一层的每一次选择，都会以 8 倍的幅度传导到你系统的最末端。

主要资料（均于 2026-09-21/22 核实）：Anthropic《Building Effective Agents》《How we built our multi-agent research system》、Claude Code 官方文档（how-claude-code-works / best-practices / costs / permissions / sandboxing / mcp）、MCP 规范 GitHub 仓库 2026-07-28 版、LangChain《The Anatomy of an Agent Harness》、METR 2025-07 RCT（arXiv:2507.09089）及 2026-02 更新、MIT/NBER Copilot 三公司实验、Uplevel 2024、DORA 2024、Stack Overflow 2024/2025 开发者调查、GitClear 2025、arXiv 2609.11999、arXiv 2509.13941、SWE-bench Verified 官网、vLLM issue #57726、LiteLLM issue #8313。文中标注"社区俗语/本文框架/作者建议"的部分不是任何一方的官方定义。