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 时代软件工程的全貌:
- Context Engineering(上下文工程):精确管理模型"看到什么"的学科
- Harness Engineering(驾驭工程):设计 Agent 运行环境的整体基础设施
- 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 Coding | Agentic 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]:
- 相关性(Relevance):模型获取的信息与当前任务精确对应
- 充分性(Sufficiency):足够但不过量
- 隔离性(Isolation):不同任务的上下文互不干扰
- 经济性(Economy):最小化 token 消耗
- 出处可溯(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 工具、脚本、Codemods | AGENTS.md、技能库、工程原则 |
| 反馈 | 静态分析、自动化测试、运行日志 | 评审 Agent、"LLM as Judge" |
Böckeler 的关键洞见:"好的 Harness 不应追求完全消除人类输入,而是将人类输入引导到最重要的地方。"
4.4 三分类法:Harness 的三种形态
Böckeler 将 Harness 分为三类,并引入了控制论中的 Ashby's Law(必要多样性定律)——"只有多样性才能吸收多样性"——来解释 Harness 的复杂度必须匹配它所管理的系统的复杂度:
可维护性 Harness(Maintainability Harness) 调节内部代码质量。工具丰富(Linter、LSP),最容易实现。 前馈:代码规范文档;反馈:静态分析、类型检查
架构适配性 Harness(Architecture Fitness Harness) 定义并检查架构特征,类似"适应度函数"。 前馈:性能要求、依赖规则;反馈:性能测试、架构检查
行为 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.md、tech_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-forward 等 | Agent 准确理解工具用途 |
| 推理轨迹保留 | 中间推理步骤保留在上下文 | 删除后 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 |
| 需要运行时管理轮次、工具执行、Guardrails | Agents 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。
参考文献
BotBeat, "Software 3.0: Karpathy's Vision for 'VibeCoding' and 'Context Engineering'," 2026-03-30. https://botbeat.ai/posts/cmnczfkpf000t01s68s4iomhm ↩︎
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 ↩︎
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 ↩︎
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/ ↩︎
同上。 ↩︎
Sat Duggal, "Context Engineering vs Prompt Engineering," DataHub Blog, 2026-04-10. https://datahub.com/blog/context-engineering-vs-prompt-engineering/ ↩︎
Ilia Ilinskii, "7 Steps to Context Engineering (2026)," Rephrase, 2026-03-12. https://rephrase-it.com/blog/7-steps-to-context-engineering-2026 ↩︎
Anthropic / Boris Cherny, Claude Code Architecture, Anthropic Blog, 2025–2026. ↩︎
Mitchell Hashimoto, "My AI Adoption Journey," mitchellh.com, 2026-02-05. https://mitchellh.com/writing/my-ai-adoption-journey ↩︎
Birgitta Böckeler, "Harness Engineering for Coding Agent Users," martinfowler.com, 2026-04-02. https://martinfowler.com/articles/harness-engineering.html ↩︎
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 ↩︎
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 ↩︎
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/ ↩︎
Cloudflare, "Code Mode: give agents an entire API in 1,000 tokens," 2026-02. 转引自 web4agents.org. ↩︎
OpenAI, "The next evolution of the Agents SDK," 2026-04-15. https://openai.com/index/the-next-evolution-of-the-agents-sdk/ ↩︎ ↩︎
Harvard, "Safety Under Scaffolding," arXiv:2603.10044, 2026-03. N=62,808 次实验。 ↩︎
Cordum, "Agent Governance Maturity Model," cordum.com, 2026-03. ↩︎