Skip to content

2026 年工程范式革命:从 Vibe Coding 到 Harness Engineering 全景解析

1. 引言:一场悄然发生的工程革命

2026 年初,软件工程领域正经历一场前所未有的范式跃迁。这场革命没有发布会,没有里程碑,只有每天在 GitHub、Slack 和技术博客上悄悄蔓延的洞察与实践。

故事的线索可以从 Andrej Karpathy 的一条 X 帖子开始讲起。2025 年 12 月,这位前 OpenAI 联合创始人写道:

"People who aren't keeping up even over the last 30 days already have a deprecated world view on this topic."(即便是过去 30 天没有跟上的人,对这个话题的认知已经过时了。)

三个月后,他已经从"80/20"(自己写 80% 的代码,把 20% 交给 AI)转变为"2/98"——只有 2% 的代码还由他亲手键入。

这不是个人的习惯改变,而是整个行业的范式转变。2026 年初,以下三个相互关联的工程概念迅速成形,共同描绘出 AI Agent 时代软件工程的全貌:

  1. Context Engineering(上下文工程):精确管理模型"看到什么"的学科
  2. Harness Engineering(驾驭工程):设计 Agent 运行环境的整体基础设施
  3. MCP(模型上下文协议):AI Agent 集成工具的通用标准

本文将系统梳理这三个范式的起源、核心框架、工业实践和最新进展。

2. 范式演进的三代历史

2.1 三代工程学科的演进

要理解 2026 年发生了什么,必须先看清从 2023 年开始的演进轨迹。

维度Prompt Engineering(2023)Context Engineering(2024–2025)Harness Engineering(2025–2026)
关注点措辞与指令技巧信息检索与上下文设计整体 Agent 运行基础设施
范围单次查询上下文管线约束 + 信息 + 验证 + 纠正
层级最内层中间层最外层(包含前两者)
隐含假设好的提示 = 好的输出好的上下文 = 好的输出好的环境 = 可靠的输出
失败模式措辞不当信息缺失约束缺失、验证不足

这三层不是替代关系,而是嵌套关系:Harness Engineering 包含 Context Engineering,Context Engineering 包含 Prompt Engineering。

2.2 Karpathy 的宏观叙事:Software 3.0

Andrej Karpathy 在 2026 年 3 月提出了一个更大的框架——Software 3.0[1]

  • Software 1.0:手写 C++/Python/Java,程序员是主角
  • Software 2.0:神经网络,通过数据和优化"写程序"
  • Software 3.0:自然语言指令 + Agent,人是导演,AI 是演员

在 Software 3.0 时代,Karpathy 认为决定性技能不再是如何写 Prompt,而是 Context Engineering——"提供给 AI 恰到好处的背景信息,既不让它淹没在噪声中,也不让它信息匮乏"[2]

Karpathy 本人还创建了 AutoResearch 项目——一套自主研究 Agent,能够设计实验、修改训练代码、优化超参数,完全无需人类干预,在单台 GPU 上 2 天内运行了 700 个实验,发现了 20 项训练优化。他将此视为"Loopy Era"(循环时代)的开端:Agent 在代码和研究上运行持续自我改进的循环[3]

2.3 从 Vibe Coding 到 Agentic Engineering:Karpathy 的个人旅程

Karpathy 在 2025 年 2 月首创了"Vibe Coding"这个词——一种放松、直觉化的 AI 辅助编程方式,接受 AI 生成的差异而不深度审查,快速迭代。

但到了 2026 年,他已经不再使用这个词了。在 No Priors 播客中,他宣布自己已进入 Agentic Engineering 阶段:

"Vibe coding is casual iteration; agentic engineering is disciplined autonomy."(Vibe coding 是随性迭代;Agentic engineering 是有纪律的自主性。)

关键区别在于:

维度Vibe CodingAgentic Engineering
开发者角色用户(接受 AI 差异)架构师/协调者
AI 角色助手自主 Agent 团队
可靠性低(适合原型)高(适合生产)
速度优势快速原型252x 更快的功能完成[4]
核心技能写好 Prompt上下文设计 + 验证设计

3. Context Engineering:从"如何措辞"到"给什么信息"

3.1 为什么 Prompt Engineering 不够用了

Karpathy 给出了最精准的定义[5]

"Context engineering is the delicate art and science of filling the context window with just the right information." (上下文工程,是将恰到好处的信息填入上下文窗口的精妙艺术与科学。)

ThoughtWorks 工程师 Bharani Subramaniam 补充道:

"Context engineering is curating what the model sees so that you get a better result."(上下文工程是筛选模型看到什么,以获得更好的结果。)

DataHub 在 2026 年 4 月发布的调研揭示了这一领域的重要性[6]

  • 95% 的 IT 和数据领导者认为上下文工程对 AI Agent 规模化至关重要
  • 83% 认为没有上下文平台,Agentic AI 无法达到生产价值
  • 89% 的团队计划在 2026 年投资上下文基础设施

3.2 Prompt vs Context:实用决策框架

场景应该用什么
单次任务,自包含,模型已有所需知识Prompt Engineering
重复任务,需要反复解释相同背景Context Engineering
长对话中输出质量下降(上下文腐烂)Context Engineering
花在 Prompt 上的时间多于任务本身Context Engineering

3.3 上下文工程的五个设计维度

上下文工程不是写更长的系统提示,而是设计信息环境[7]

  1. 相关性(Relevance):模型获取的信息与当前任务精确对应
  2. 充分性(Sufficiency):足够但不过量
  3. 隔离性(Isolation):不同任务的上下文互不干扰
  4. 经济性(Economy):最小化 token 消耗
  5. 出处可溯(Provenance):信息的来源可追溯,防止幻觉

上下文腐烂(Context Rot) 是 Context Engineering 失败的典型形态:随着上下文积累,关键信息被稀释,在 32K–64K token 处出现准确率悬崖式下跌。

4. Harness Engineering:决定成败的 80% 因素

4.1 核心公式与核心发现

Agent = Model + Harness

这是 2026 年最重要的工程认知之一。Anthropic 的 Claude Code 代码库中,95% 是 Harness 代码,只有 5% 是模型调用[8]。这颠覆了"AI 应用就是调 API"的直觉。

两个团队使用相同的模型,仅凭 Harness 设计差异,任务完成率可以相差 40 个百分点。LangChain 的 deep agents 团队通过纯 Harness 改进(不换模型),在 Terminal Bench 2.0 上从 52.8% 提升到 66.5%。

4.2 什么是 Harness?四动词框架

"Harness" 来自马术——缰绳、马鞍、马嚼子。模型是具有强大力量的"马",Harness 是将其力量导向有用目标的控制系统。Mitchell Hashimoto 在 2026 年 2 月 5 日正式确立了 "Harness Engineering" 这个术语[9]

"每次发现 Agent 犯错,都要花时间工程化一个解决方案,确保它永远不再犯同样的错误。"

Harness Engineering 通过四个核心动作管理 Agent 行为:

  • 约束(Constrain):沙箱隔离、权限模型、规则强制。好的约束是导向(reins),不是绳索(leash)
  • 告知(Inform):上下文工程、AGENTS.md 文件作为项目入口、动态信息检索
  • 验证(Verify):机械式不变性、测试套件、交叉 Agent 评审
  • 纠正(Correct):自动反馈循环、人类升级路径、自动回滚

4.3 Böckeler 框架:Guides vs Sensors 与 2×2 矩阵

ThoughtWorks 首席工程师 Birgitta Böckeler 在 martinfowler.com 发表的完整文章[10](2026 年 4 月 2 日)提供了最系统的分类框架。

最基本的区分是前馈(Guides)vs 反馈(Sensors)

类型方向作用时机示例
Guides(引导)前馈Agent 行动之前AGENTS.md、代码风格、原则文档
Sensors(感知)反馈Agent 行动之后类型检查器、测试、日志、安全扫描

进一步细化为 2×2 矩阵:

计算型(Computational)推理性(Inferential)
前馈LSP、CLI 工具、脚本、CodemodsAGENTS.md、技能库、工程原则
反馈静态分析、自动化测试、运行日志评审 Agent、"LLM as Judge"

Böckeler 的关键洞见:"好的 Harness 不应追求完全消除人类输入,而是将人类输入引导到最重要的地方。"

4.4 三分类法:Harness 的三种形态

Böckeler 将 Harness 分为三类,并引入了控制论中的 Ashby's Law(必要多样性定律)——"只有多样性才能吸收多样性"——来解释 Harness 的复杂度必须匹配它所管理的系统的复杂度:

  1. 可维护性 Harness(Maintainability Harness) 调节内部代码质量。工具丰富(Linter、LSP),最容易实现。 前馈:代码规范文档;反馈:静态分析、类型检查

  2. 架构适配性 Harness(Architecture Fitness Harness) 定义并检查架构特征,类似"适应度函数"。 前馈:性能要求、依赖规则;反馈:性能测试、架构检查

  3. 行为 Harness(Behaviour Harness) 引导并感知功能行为。 前馈:功能规格说明;反馈:AI 生成的高覆盖率测试套件

4.5 六大核心原则

综合所有文献,Harness Engineering 的六个核心原则是:

原则一:环境 > 智能(Environment > Intelligence) 不要问"哪个模型最好",而要问"我们的 Harness 需要什么才能可靠地产出所需输出?"

原则二:约束即赋能(Constraints as Enablement) 好的边界让 Agent 在安全范围内更自信地行动,而不是在无边界的情况下犹豫不决。

原则三:验证闭环(Verification Loops) 信任,但要验证。每一步。不要等到最后才验证——将验证嵌入每一步。

原则四:上下文工程(Context Engineering) 不要问"Prompt 怎么写",而要问"Agent 在每一步需要什么信息,如何高效检索?"

原则五:反馈 > 前馈(Feedback over Feedforward) 先建好验证循环(Sensors),再优化指导文档(Guides)。

原则六:整体设计 > 碎片拼凑(Holistic Design over Assembly) 五大组件(上下文、编排、工具、验证、运维)是统一设计的整体,缺少任何一个都会导致系统性脆弱。

5. 工业实践全景:各大公司的 Harness 设计哲学

5.1 OpenAI:极端 Harness 工程与"暗工厂"

Ryan Lopopolo 在 Latent Space 播客(2026 年 4 月 7 日)[11] 深度披露了 OpenAI Frontier 团队的实验细节,整集被称为"极端 Harness 工程":

  • 核心指标:1M 行代码、每天 10 亿 token、0% 人工编写代码、0% 合并前人工审查
  • 构建循环黄金法则:一分钟成为内循环(inner loop)的上限,超过则分解构建图
  • 软件需要"对 Agent 可读":代码要像为工程师设计一样,为模型设计
  • 评审 Agent 的偏置:评审 Agent 偏向合并,只浮现 P2 或更低优先级问题
  • 代码是可抛弃的:当 Agent 可以随时重写,代码本身的"可读性"让位于"可重生成性"
  • Harness 成为盒子,模型决定路径:从预定义的脚手架到由推理模型主导的工作流

关键洞见:"人类注意力,而不是 token,成为了真正的瓶颈。"

Markdown 文件(如 core_beliefs.mdtech_tracker.md)成为轻量级的表格化知识库,让 Codex 能够追踪决策状态。Agent 甚至可以自行开工单、根据会话日志反思并修改自己的工作流。

5.2 Anthropic:Bash is All You Need

Claude Code 的核心设计哲学是:尽可能少的抽象层。架构分为五层:

层次内容
用户交互层CLI 界面、会话管理
Harness 编排层工具调用循环、上下文管理
安全沙箱层权限控制、命令过滤
工具执行层Bash、文件操作、Git
模型调用层Claude API

Ralph Loop(Boris Cherny 提出):上下文接近满时,保存状态到磁盘,启动新会话读取历史继续工作——实现"无限上下文"的实践方案。

5.3 Manus AI:随机梯度下降的 Harness 演化

Manus 团队将其 Harness 演化命名为"Stochastic Graduate Descent"——通过反复失败和重写逼近最优解:

  • 6 个月内进行了 4 次完全重写
  • KV-Cache 优化:系统提示 cached 价格 vs uncached 价格差 10 倍($0.30 vs $3.00 每百万 token)
  • 状态机 + logits masking:在输出层约束行为,消除格式错误导致的失败
  • todo.md 持久化:Agent 将待办事项写入文件系统,实现跨会话状态持久化

5.4 Cursor:推理轨迹是基础设施

Cursor 的四个核心支柱:

支柱实现方式价值
持久规则.cursor/rules/ Markdown 文件跨会话保留项目约定
隔离环境git worktree 自动隔离并行任务互不干扰
语义化工具名shell-forwardAgent 准确理解工具用途
推理轨迹保留中间推理步骤保留在上下文删除后 30% 性能回归

推理轨迹不是可优化删减的冗余,而是 Agent 性能的关键基础设施。

5.5 GitHub Copilot:Rubber Duck 模式

双 AI 审查机制——第二个独立模型对第一个模型的输出进行批判性审查:实验数据显示,Rubber Duck 机制恢复了 74.7% 的 Claude Opus 与 Claude Sonnet 之间的性能差距。即用更便宜的 Sonnet + Rubber Duck,可以接近更贵的 Opus 的质量。

5.6 Steve Yegge:Gas Town 并行架构

同时运行 20–30 个 Claude Code 实例,三层角色分工:

  • Mayor(市长):高层任务规划与协调
  • Polecats(工人):执行具体编码任务的并行 Agent
  • Beads(珠子):轻量级信息传递单元

实际案例:17 天内构建了 189,000 行 Go 代码的完整项目。

5.7 AgentsMesh:52 天自举验证

AgentsMesh 项目(1,441 GitHub Stars)用 AgentsMesh 来构建 AgentsMesh 本身,52 天内:

  • 965,687 行代码吞吐量
  • 356,220 行生产代码
  • 600 commits,1 名工程师

三大工程原语:隔离(每个 Agent 在独立 Git worktree + 沙箱中运行)、分解(Tickets/Loops)、协调(Channels/Bindings)。

6. MCP:AI 集成的 USB-C 标准

6.1 什么是 MCP

Model Context Protocol(MCP) 是 Anthropic 于 2024 年 11 月推出的开放标准,为 AI Agent 连接外部工具、数据源和服务提供了统一接口。官方类比是:

"MCP 是 AI 的 USB-C 接口。" [12]

2025 年 12 月,MCP 被捐赠给 Linux 基金会旗下的 Agentic AI Foundation(AAIF),与 Kubernetes、Linux 治理模式相同,实现跨厂商开放协作。截至 2026 年初,MCP 已有:

  • 9700 万 月度 SDK 下载量
  • Anthropic、OpenAI、Google、Microsoft 全部支持
  • 数百家 Fortune 500 公司采用

6.2 MCP 的架构:N×M → N+M

MCP 解决的核心问题是 N×M 集成复杂度:在 MCP 之前,M 个工具需要为 N 个 AI 系统各写一套集成代码,共 N×M 个接口。MCP 把这降为 N+M:

6.3 MCP 的 2026 年重要更新

MCP Tool Search(工具搜索)[13]:解决了"工具上下文爆炸"问题——50+ 工具的描述可消耗 77,000 token。MCP Tool Search 让模型按需检索工具定义,每次只加载 3–5 个:

  • Token 开销从 ~77,000 降至 ~8,700(85% 减少
  • 任务准确率从 49% 提升至 74%(在某些基准测试上)
  • 另一组测试:从 79.5% 提升至 88.1%

MCP Apps(2026 年 1 月):工具可以返回交互式 UI 句柄,而非仅文本。Claude 桌面、VS Code Insiders、ChatGPT 均开始支持。

Cloudflare Code Mode 最佳实践:不是把 2,500 个 API 端点暴露为 2,500 个工具(会消耗百万 token),而是只暴露两个工具(search() + execute()),让 Agent 发送可执行代码在服务器端运行,token 占用固定在 ~1,000 token,无论 API 有多大[14]

6.4 MCP 与 Harness Engineering 的关系

MCP 是 Harness Engineering 工具集成层(Tool Integration Layer)的标准化协议:

MCP 让工具集成从 Harness Engineering 的"重复造轮子"问题中解放出来,使工程师能专注于约束、验证和编排层。

7. OpenAI Agents SDK:Harness 的官方形式化

7.1 四月重大更新

2026 年 4 月 15 日,OpenAI 发布了 Agents SDK 的重大更新[15],正式提出了"model-native harness(模型原生驾驭层)"概念:

"We're introducing a model-native harness that lets agents work across files and tools on a computer, plus native sandbox execution for running that work safely."

此次更新的核心能力:

能力说明
模型原生 Harness跨文件与工具的统一工作环境
可配置记忆Agent 的状态持久化与上下文管理
沙箱感知编排工具执行的安全边界与隔离
文件系统工具Codex 风格的文件操作原语
MCP 集成内置 MCP 协议支持
Shell 工具命令执行能力
Apply-Patch文件差异式编辑
原生沙箱执行安全长任务容器环境

7.2 关键设计原则:"Harness 与计算分离"

OpenAI 在文档中明确指出[15:1]

"Agent systems should be designed assuming prompt-injection and exfiltration attempts. Separating harness and compute means operators can route subagents to isolated environments, and parallelize work across containers for faster execution."

这与 Harness Engineering 学科的核心主张高度吻合:Harness 是独立的、可审计的控制平面,计算是可替换的执行平面

7.3 Responses API vs Agents SDK

使用场景选择
需要自己管理工具循环和状态Responses API
工作流短暂,主要是返回模型响应Responses API
需要运行时管理轮次、工具执行、GuardrailsAgents SDK
Agent 需要跨多步骤生成制品Agents SDK
需要真实工作区或可恢复执行Agents SDK(Sandbox)

8. 设计模式速查目录

8.1 核心执行模式

模式名核心机制关键数据
Ralph Loop上下文接近满时保存状态到磁盘 → 新会话读取历史继续实现"无限上下文"
Rubber Duck第二个 AI 审查第一个 AI 的输出恢复 74.7% Opus-Sonnet 差距
Reasoning Sandwich工具调用前后各插入显式推理步骤贡献 +12.6% 性能提升
Generator-Evaluator主 Agent 生成,评审 Agent 验证两个独立推理过程的分歧是信号
One-Minute Loop构建循环上限设为 1 分钟,超时则分解OpenAI Frontier 的强制规则

8.2 上下文与记忆模式

模式名机制适用场景
File System as Context将长期状态写入文件系统多会话连续任务
todo.md Persistence任务状态写入 todo.md复杂多步任务
ESAA(事件溯源)状态变更记为不可变事件流审计需求场景
Context Compaction原生上下文压缩,保留关键决策历史长任务运行

8.3 六类反模式(Breunig 分类)

反模式描述危害
Context Dumping无差别塞入所有信息信息过载,关键内容被稀释
Context Starvation过度压缩,信息不足推理质量下降
Context Echo相同信息反复出现浪费 token,强化错误假设
Context Clashing上下文中存在矛盾指令行为不稳定
Format Soup混合格式(JSON/Markdown/纯文本)解析错误,输出格式混乱
Ghost Context引用不可访问或已过期信息幻觉增加,任务失败

8.4 工具设计最佳实践

工具悬崖效应(Tool Cliff Effect)

  • ~10 个工具是黄金比例,准确率最高
  • 超过 30 个工具性能开始下降
  • 超过 100 个工具通常导致任务失败
  • 移除 80% 冗余工具后,某 Agent 准确率从 80% → 100%

MCP 的工具设计原则:

  • 将相关操作分组为带 action 参数的单个工具
  • 明确区分只读工具和写操作工具
  • 工具名称语义化(get_user_by_email 而非 get_user

9. 学术研究进展速览

2026 年初,学术界在形式化方法和可靠性研究上取得了一系列重要进展:

最重要的发现:Harvard 的大规模研究(N=62,808 次实验)证明,Harness 形式本身是安全变量——即脚手架设计会影响安全测量结果,不能只评估模型而忽视 Harness(NNH=14:平均每 14 次特定配置,就有 1 次额外的不安全行为)[16]

10. 治理成熟度:你的团队在哪里?

10.1 Agent Governance Maturity Model

大多数企业处于 L1–L2 阶段[17]

级别名称特征
L0无治理Agent 无约束运行,无审计
L1基础护栏工具白名单、基础日志
L2流程治理审批工作流、人工审查节点
L3策略治理声明式安全策略、自动合规检查
L4舰队治理多 Agent 协调治理、自适应风险管理

10.2 可观测性工具现状

OpenTelemetry 正成为 Agent 可观测性的基础协议,各工具逐步统一:

  • MLflow Tracing(开源):实验跟踪与 Agent 追踪
  • Langfuse(开源):调用链追踪、成本分析
  • Braintrust(商业):LLM 评测、A/B 测试
  • OpenTelemetry(标准):分布式追踪的底层协议

11. 给不同角色的核心洞见

对工程师

  • 角色从"代码实现者"转向"环境设计者"
  • 投资 AGENTS.md、测试基础设施、工具设计的 ROI 高于投资 Prompt 优化
  • 好的类型系统 > 好的代码评审——Agent 需要即时信号
  • 构建快速的内循环(目标:< 1 分钟)是 Agent 生产力的关键乘数

对技术领导者

  • 不要问"哪个模型最好",而要问"我们的 Harness 需要什么"
  • 为 Harness 分配 2–3 倍于 Agent 逻辑本身的工程投入
  • 度量 Harness 质量:Agent 任务完成率、验证覆盖率、漂移检测率
  • MCP 已成为工具集成层的事实标准,尽早采用可避免重复造轮子

对平台工程师

  • Platform Engineering 和 Harness Engineering 正在融合
  • Golden Path 概念同时适用于人类开发者和 AI Agent
  • 关键差异:为 Agent 设计时,Sensors(验证)比 Guides(指导)优先级更高
  • 治理成熟度目标:努力从 L1/L2 升级到 L3

12. 结语:范式已经切换,工程师的角色也在切换

2026 年初,三个相互强化的工程范式共同构成了 AI Agent 时代的基础设施图景:

Karpathy 总结得最为精准:

"The value shifted from execution to judgment. Vibe coding was about execution — prompt, generate, ship. Agentic engineering is about judgment — architecture, verification, orchestration." (价值从执行转向了判断。Vibe coding 关注执行——提示、生成、发布。Agentic engineering 关注判断——架构、验证、编排。)

在 AI Agent 时代,工程师的核心竞争力不再是"写什么代码",而是"设计 Agent 在什么环境中运行"。环境、约束、验证、纠正——这些看似"外围"的基础设施,才是决定 Agent 可靠性的 80% 因素。

不是模型,不是 Prompt,是 Harness。


参考文献


  1. BotBeat, "Software 3.0: Karpathy's Vision for 'VibeCoding' and 'Context Engineering'," 2026-03-30. https://botbeat.ai/posts/cmnczfkpf000t01s68s4iomhm ↩︎

  2. Andrej Karpathy, X post, June 2025. 转引自 HiveTrail, "Context Engineering vs Prompt Engineering: What the Shift Means for Developers (2026)," 2026-04-12. https://hivetrail.com/blog/context-engineering-vs-prompt-engineering-developers ↩︎

  3. Brian Wang, "Andrej Karpathy on Code Agents, AutoResearch and the Self Improvement Loopy Era of AI," NextBigFuture.com, 2026-03-20. https://www.nextbigfuture.com/2026/03/andrej-karpathy-on-code-agents-autoresearch-and-the-self-improvement-loopy-era-of-ai.html ↩︎

  4. Aravind Balakrishnan, "From Vibe Coding to Agentic Engineering: Andrej Karpathy's Vision for the Future of Software Development," lowtouch.ai, 2026-02-11. https://www.lowtouch.ai/from-vibe-coding-to-agentic-engineering-andrej-karpathys-vision-for-the-future-of-software-development/ ↩︎

  5. 同上。 ↩︎

  6. Sat Duggal, "Context Engineering vs Prompt Engineering," DataHub Blog, 2026-04-10. https://datahub.com/blog/context-engineering-vs-prompt-engineering/ ↩︎

  7. Ilia Ilinskii, "7 Steps to Context Engineering (2026)," Rephrase, 2026-03-12. https://rephrase-it.com/blog/7-steps-to-context-engineering-2026 ↩︎

  8. Anthropic / Boris Cherny, Claude Code Architecture, Anthropic Blog, 2025–2026. ↩︎

  9. Mitchell Hashimoto, "My AI Adoption Journey," mitchellh.com, 2026-02-05. https://mitchellh.com/writing/my-ai-adoption-journey ↩︎

  10. Birgitta Böckeler, "Harness Engineering for Coding Agent Users," martinfowler.com, 2026-04-02. https://martinfowler.com/articles/harness-engineering.html ↩︎

  11. Ryan Lopopolo, "Extreme Harness Engineering for Token Billionaires: 1M LOC, 1B toks/day, 0% human code, 0% human review," Latent Space Podcast, 2026-04-07. https://www.latent.space/p/harness-eng ↩︎

  12. Metosys, "Model Context Protocol (MCP): The Complete Enterprise Guide (2026)," 2026-04-04. https://www.metosys.com/blog/model-context-protocol-mcp-enterprise-guide-2026 ↩︎

  13. AINetizens, "What Is Model Context Protocol (MCP)? Anthropic's Complete Guide + 2026 Focused Updates," 2026-03-15. https://ainetizens.com/model-context-protocol-anthropic-guide-2026/ ↩︎

  14. Cloudflare, "Code Mode: give agents an entire API in 1,000 tokens," 2026-02. 转引自 web4agents.org. ↩︎

  15. OpenAI, "The next evolution of the Agents SDK," 2026-04-15. https://openai.com/index/the-next-evolution-of-the-agents-sdk/ ↩︎ ↩︎

  16. Harvard, "Safety Under Scaffolding," arXiv:2603.10044, 2026-03. N=62,808 次实验。 ↩︎

  17. Cordum, "Agent Governance Maturity Model," cordum.com, 2026-03. ↩︎