Claude Code把复杂度放在工作过程组织（CLAUDE.md、Skill按需加载、Subagent隔离），Codex把复杂度放在边界（沙箱决定碰得到什么、审批决定什么要停），DSH把复杂度放在可拆卸（一切皆插件、追加式Session Log）——“同一项任务控制权交给谁”这三条路，到底该按“你的团队最怕什么失控”来选？

摘要：编码智能体（coding agent）的工程化竞争，已经从“模型能不能写对代码”转向“任务执行过程中控制权如何分配”。本文提出一条贯穿性分析主线：控制权不是单一开关，而是沿“过程—边界—结构”三个维度分布的可配置量。Claude Code 把复杂度前置到工作过程组织（CLAUDE.md 约定、Skill 按需加载、Subagent 上下文隔离），Codex 把复杂度外置到执行边界（沙箱决定可达面、审批决定停顿点），DSH 类可拆卸架构把复杂度下沉到系统结构（一切皆插件、追加式 Session Log）。本文先给出控制权分布的形式化描述，再逐条拆解三条技术路线的机制、代价与失效边界，随后以“团队最怕什么失控”为决策变量构建选型矩阵与落地步骤，最后讨论三条路线正在发生的收敛趋势与可验证的前沿预判。全文约 12600 字，引证文献 62 篇，其中近三年文献占比约 56%。

目录

一、导语：控制权问题为什么在 2025 年之后才真正浮现

如果只看 2023 至 2024 年的编码智能体评测，讨论焦点几乎全部集中在单点能力上：HumanEval 的 pass@1、SWE-bench 的解决率、上下文窗口长度、工具调用准确率。这些指标回答的是“模型在受控输入下能否产出正确补丁”。但当一个智能体被放进真实仓库、被允许运行 shell、被授权提交 PR、被挂进 CI 流水线之后，问题性质就变了：它不再是一道函数题，而是一个持续数十分钟、涉及数十次工具调用、可能修改生产配置的执行过程。此时决定工程成败的，往往不是模型某一步写得好不好，而是“谁在什么时候有权让它停下来、有权让它碰什么、有权决定它留下的痕迹如何被审计”。

这一转变有清晰的外部信号。2024 年 11 月，Anthropic 在工程博客中系统阐述了“构建有效智能体”的实践，明确区分 workflow 与 agent，并强调工具设计与环境反馈对可靠性的决定性作用（Anthropic, 2024）。2025 年，OpenAI 在 Codex 的产品文档中把“沙箱网络默认关闭、审批模式可配置”写成一级概念，而不是安全附录（OpenAI, 2025a）。同期，围绕 MCP（Model Context Protocol）的插件化生态迅速扩张，把“能力以可插拔方式接入”变成事实标准（Anthropic, 2024b）。本文评述：这些动作指向同一个底层命题——智能体的可靠性不是模型属性，而是系统属性；而系统属性的核心，是控制权的分布方式。

因此，把 Claude Code、Codex 与 DSH 类可拆卸架构放在一起比较，若只比较“谁更聪明”，会得出几乎无意义的结论。更有解释力的比较维度是：它们各自把复杂度放在了哪里，因而把控制权交给了谁。Claude Code 选择让团队通过文档与技能定义来组织工作过程；Codex 选择让平台通过沙箱与审批来划定执行边界；DSH 选择让架构通过插件与追加日志来保证可拆卸与可回放。三条路线没有绝对优劣，只有与团队风险画像的匹配度差异。本文的全部章节，都服务于把这一判断变成可操作的决策工具。

二、背景与问题定义：从“生成质量”到“执行治理”的范式迁移

2.1 三个可观测的行业事实

第一，评测重心正在从“补丁正确率”转向“端到端任务完成率与成本”。SWE-bench 及其 Verified 子集把真实 GitHub issue 作为任务，要求智能体在仓库中定位、修改并自测（Jimenez et al., 2024）。这类评测天然包含多步工具调用，因而暴露了过程组织问题：上下文如何压缩、失败如何重试、子任务如何隔离。第二，工具协议标准化加速。MCP 于 2024 年末开源后，社区迅速出现大量 server 实现，使“能力接入”与“模型推理”解耦（Anthropic, 2024b）。第三，安全事件推动边界设计前置。2025 年多起围绕智能体命令执行的讨论（包括对“命令注入经由工具返回值”的风险分析）促使厂商把沙箱与审批做成默认可见的产品概念，而非隐藏配置（OpenAI, 2025a；OWASP, 2025）。

本文评述：这三个事实并非彼此独立。评测重心转移要求智能体长时间自主运行；长时间自主运行必然放大工具面的风险；风险放大又倒逼边界机制产品化。三者共同把“执行治理”（execution governance）推到了工程前台。所谓执行治理，本文定义为：在智能体执行任务的全过程中，对可达资源、可执行动作、可中断时机、可追溯记录进行制度化约束的一整套机制。它不等同于模型对齐，也不等同于传统 RBAC，而是二者的交集加上时间维度。

2.2 问题定义：控制权归属的四个追问

为了让后续比较可操作，本文把“控制权交给谁”拆成四个可回答的追问：其一，可达面由谁定义——智能体能读写哪些路径、访问哪些网络端点、调用哪些外部服务；其二，停顿点由谁设置——哪些动作必须先获人工批准，批准粒度是命令级、文件级还是任务级；其三，过程由谁组织——任务如何被拆解、上下文如何被裁剪、子任务如何隔离；其四，痕迹由谁保存——执行日志是覆盖式还是追加式，能否离线回放与责任归属。这四个追问构成本文的比较坐标系，也构成后文选型矩阵的行。

需要强调的是，这四个维度并非正交独立。可达面越宽，停顿点设计就越关键；过程组织越复杂，痕迹保存的保真度要求就越高。笔者认为，工程上真正困难的不是单点做强，而是在四个维度之间取得与团队风险承受力一致的平衡。这也解释了为什么同一套工具在不同团队的评价会截然相反：它们的风险画像不同，因而对同一控制权分布的效用判断不同。

三、分析主线：控制权的三维分解与形式化描述

3.1 三维分解：过程、边界、结构

本文提出的主线是：控制权沿三个维度分布，分别是过程维（P）、边界维（B）与结构维（S）。过程维刻画“任务如何被组织与推进”，包括约定文档、技能加载、子智能体隔离、上下文预算分配；边界维刻画“执行被允许到什么程度”，包括沙箱能力、网络策略、审批阈值；结构维刻画“系统如何被组装与回放”，包括插件边界、日志模型、状态可重建性。三条路线分别在这三个维度上投入了不成比例的工程复杂度，从而形成了不同的控制权重心。

为便于推理，可给出一个粗粒度的形式化描述。设一次任务执行为轨迹 τ = (a₁, a₂, …, aₙ)，其中 aᵢ 为第 i 步动作（读文件、执行命令、调用工具等）。定义控制权配置 C = (P, B, S)，其中 P 决定动作序列的生成与裁剪策略，B 决定每个动作的许可集合 Allow(aᵢ) 与需审批集合 Approve(aᵢ)，S 决定轨迹的持久化形式 Log(τ)。一次执行被判定为“受控”，当且仅当对任意 i，aᵢ ∈ Allow(aᵢ) ∪ Approve(aᵢ) 且 Log(τ) 可重建。本文评述：这个描述的价值不在于数学严格性，而在于它把“控制权”从模糊口号变成可逐项检查的工程清单——任何一条路线，都可以用 P/B/S 三栏去问“它到底在哪一栏做了重投入”。

3.2 复杂度守恒：为什么必须选一个维度重投入

工程实践反复验证一个经验规律：复杂度不会消失，只会转移。若不在过程维投入，长任务的上下文漂移与子任务污染就会在运行时以失败形式暴露；若不在边界维投入，一次误执行的破坏半径就会在事故后暴露；若不在结构维投入，系统演化到第三、第四个集成方时就会出现“改一处、崩三处”的耦合债。三条路线本质上是对“复杂度放在哪里”的三种不同回答，而不是“有没有复杂度”的差别。

笔者认为，理解这一点对选型至关重要。很多团队在评估时倾向于问“哪个更强”，但更有效的问题是“我们愿意在哪一维承担持续维护成本”。过程维的维护成本体现为文档与技能的持续更新；边界维的维护成本体现为策略配置与审批流程的人力；结构维的维护成本体现为插件接口的版本治理。三者都需要长期投入，只是投入形态不同。选型即选债，关键在于选择一种团队有能力长期偿还的债。

四、路线一：Claude Code——把复杂度放进工作过程组织

4.1 机制拆解：CLAUDE.md、Skill 按需加载、Subagent 隔离

Claude Code 的设计取向是把“团队约定”变成一等公民。CLAUDE.md 是一个放在仓库中的约定文件，用于声明构建命令、代码风格、目录约定、禁止事项等，智能体在会话开始时读取并据此调整行为。它的工程意义在于：把隐性知识显性化为可版本控制的文本，使智能体的行为可以随仓库一起 review、一起回滚。Skill 机制则进一步把“能力”做成按需加载的模块：技能以目录形式组织，包含说明与可选脚本，只有在任务相关时才被载入上下文，从而避免一次性塞满窗口。Subagent 隔离解决的是上下文污染问题：主智能体可以把探索性、噪声大的子任务（如大范围搜索、依赖分析）委派给子智能体，只回收结论而不回收过程。

本文评述：这三项机制的共同点是把控制权交给“写文档的人”而非“配策略的人”。团队通过编辑 CLAUDE.md 和技能目录来间接控制智能体行为，控制手段是自然语言与目录结构，而不是权限矩阵。这带来一个显著优点：控制逻辑与代码同仓、同 PR、同 review，治理成本被分摊到日常开发流程中。但也带来一个显著代价：约定是“软约束”，智能体可能理解偏差、可能忽略、可能在不同会话中表现不一致。换言之，过程维投入换来了灵活性，却没有换来硬保证。

4.2 适用条件与失效边界

这条路线在以下条件下表现最好：仓库结构清晰、约定稳定、任务以“在既有代码库中做增量修改”为主、团队愿意维护文档。反之，在约定频繁变动、多仓库异构、或需要强合规审计的场景中，软约束的不足会迅速显现。一个可验证的观察是：当 CLAUDE.md 超过一定长度后，其边际效用下降，因为关键约定被淹没在细节中。这与长上下文中的“中间遗忘”现象一致（Liu et al., 2024）。因此，过程维投入并非越多越好，而是需要分层组织：短小的顶层约定 + 按需加载的细分技能。

从控制权角度看，Claude Code 把“停顿点”主要交给人在回路中的即时判断，而非预置策略。这在探索性任务中是优点（人可以根据中间结果灵活决定），在批量任务中是缺点（人成为吞吐瓶颈）。笔者认为，这条路线最适合“人机结对、以人为主导、智能体承担高噪声子任务”的工作模式，而不适合“无人值守批处理”。理解这一点，比争论它是否“更强”更有实践价值。延伸阅读可参考 Anthropic 关于智能体构建的工程文章与 Claude Code 文档（见文末链接）。

五、路线二：Codex——把复杂度放进执行边界

5.1 机制拆解：沙箱决定碰得到什么，审批决定什么要停

Codex 的设计取向几乎相反：它不假设团队会把约定写得很完善，而是假设执行本身需要被围栏。其文档把沙箱与审批作为一级概念：沙箱限定文件系统可写范围与网络可达性（默认常为禁网或受限），审批模式则决定哪些动作需要人工确认（例如在 workspace-write 模式下对越界写入或联网操作请求批准）。这种“能力围栏 + 停顿点”的组合，把控制权从“文档作者”转移到“策略配置者”，控制手段是平台级开关而非自然语言约定（OpenAI, 2025a）。

本文评述：这条路线在安全工程上更接近传统的最小权限原则（Saltzer & Schroeder, 1975）。它的优点是提供硬保证：无论模型如何“想”，越界动作在机制上无法静默完成。缺点是它把治理成本转移给了策略维护者，并且可能牺牲任务流畅性——频繁的审批请求会打断长任务，过窄的沙箱会让智能体在需要联网查文档时卡住。因此，边界维投入的关键不是“越严越好”，而是找到与任务风险相匹配的围栏粒度。

5.2 适用条件与失效边界

Codex 路线在以下条件下最优：组织对误操作高度敏感（涉及生产配置、敏感数据、对外发布）、需要可审计的硬边界、任务可以接受一定的人工确认开销。反之，在需要大量联网调研、需要跨仓库自由读写、或追求高吞吐无人值守的场景中，边界约束会成为效率瓶颈。一个常见的工程折中是分层沙箱：对只读分析任务放宽网络、对写操作收紧路径、对发布动作强制审批。这种分层并非 Codex 独有，但它的产品化程度使其更容易落地。

从控制权角度看，Codex 把“可达面”和“停顿点”都做成了显式配置，这带来一个被低估的好处：控制策略本身成为可 review 的工件。策略文件可以进版本库、可以做变更审计、可以在事故复盘中逐条核对。笔者认为，对于受监管行业，这一点的价值可能超过模型能力的边际提升。延伸阅读可参考 OpenAI Codex 文档与沙箱设计说明（见文末链接）。

六、路线三：DSH 类可拆卸架构——把复杂度放进系统结构

6.1 机制拆解：一切皆插件、追加式 Session Log

DSH 类架构的核心主张是“可拆卸”：智能体的每一项能力——模型接入、工具、记忆、界面——都以插件形式存在，通过统一接口组装；会话状态以追加式日志（append-only session log）记录，而非可变状态。追加式日志的工程价值在于可回放、可分支、可审计：任何一次执行都可以从日志重建，任何一次实验都可以从某个检查点分叉。这与事件溯源（event sourcing）在分布式系统中的思路同源（Fowler, 2005），也与近年“可回放执行”在智能体评测中的需求相呼应（Yao et al., 2024）。

本文评述：这条路线把控制权交给“架构定义者”，控制手段是接口契约与日志模型。它的优点是演化能力强：替换模型、替换工具、替换记忆后端都不需要重写主流程；事故复盘时可以精确重放。缺点是前期架构成本高，且插件边界设计不当会导致“接口泄漏”——插件之间通过隐式共享状态耦合，可拆卸性名存实亡。笔者认为，判断一个可拆卸架构是否名副其实，最有效的检验是：能否在不修改核心代码的前提下，替换掉任意一个插件并保持日志可回放。若不能，则“可拆卸”只是宣传语。

6.2 适用条件与失效边界

这条路线适合：需要长期演化、需要多模型多工具混用、需要强复盘能力的平台型团队。它不适合：任务单一、团队规模小、追求快速上手的场景——此时架构成本难以摊薄。另一个常被忽视的边界是日志膨胀：追加式日志在长任务中会快速增大，需要配套的压缩、分段与索引策略，否则回放成本会反噬可用性。这与可观测性系统中的采样与保留策略问题同构（OpenTelemetry, 2024）。

从控制权角度看，DSH 路线的独特价值在于它同时改善了“痕迹保存”这一维：追加日志使责任归属与过程复现成为默认能力，而不是事后补丁。笔者认为，对于需要回答“这次修改是谁、在什么上下文下、基于什么信息做出的”这类问题的团队，结构维投入的回报是最直接的。延伸阅读可参考事件溯源与可回放智能体的相关讨论（见文末链接）。

七、关键数据与案例：三条路线的可观测差异

7.1 公开评测中的过程性指标

需要说明的是，三条路线并非同一评测口径下的可比对象，直接比较“解决率”意义有限。更有信息量的是过程性指标：工具调用次数、上下文占用峰值、人工干预次数、失败重试率。SWE-bench 系列提供了任务级基线（Jimenez et al., 2024），而近年关于长上下文退化的研究提供了过程性解释：随着输入增长，模型对中段信息的利用率下降（Liu et al., 2024）。这直接支持了 Claude Code 的“按需加载技能”与 Subagent 隔离设计——它们本质上是对上下文预算的主动管理。

下表为本文基于公开文档与评测描述整理的定性对照（非同一实验条件下的定量测量，标注为整合分析）：

本文评述：这张表最重要的信息不是“谁更强”，而是每一行的强弱都对应一项持续成本。团队若选择 Claude Code，就要准备好长期维护文档；若选择 Codex，就要准备好长期维护策略与审批流程；若选择 DSH 类，就要准备好长期维护插件契约。忽略成本只谈能力，是选型中最常见的错误。

7.2 一个可复现的对照实验设计（模拟数据）

为避免空谈，本文给出一个团队可自行复现的对照实验设计。取同一仓库的 20 个中等难度 issue，分别在三套配置下执行：A 组为“过程组织型”（约定文档 + 技能按需加载 + 子任务隔离），B 组为“边界约束型”（沙箱收紧 + 关键动作审批），C 组为“可拆卸型”（插件化 + 追加日志回放）。记录四项指标：任务完成率、人工干预次数、上下文峰值占用、失败后可恢复率。下表为模拟数据（用于说明指标形态，非真实测量）：

配置   完成率   人工干预/任务   上下文峰值(相对)   失败可恢复率
A      0.72     1.8            0.61              0.55
B      0.65     3.4            0.58              0.70
C      0.68     2.1            0.66              0.88
（模拟数据，仅示意指标形态；实际数值需团队自测）

这个模拟结果揭示了一个有实践意义的权衡：边界约束提高了可恢复率但抬高了干预成本，过程组织降低了上下文压力但可恢复率一般，可拆卸架构在可恢复率上占优但上下文开销略高。笔者认为，团队应把这张表当作“风险偏好映射表”来读：若最怕的是“出错后无法复盘”，C 组更合适；若最怕的是“越界操作”，B 组更合适；若最怕的是“长任务跑飞”，A 组更合适。

八、对比与局限：三条路线的失效边界

8.1 共同局限：软约束与硬约束的错配

三条路线共享一个结构性局限：它们都只能在自己的维度上提供强保证，而在其他维度上依赖弱机制。Claude Code 的过程组织再完善，也无法阻止一次越界写入（除非叠加边界机制）；Codex 的沙箱再严，也无法保证长任务的上下文不漂移；DSH 的日志再完整，也无法替代策略层面的审批设计。这意味着任何单一路线都不足以覆盖完整治理需求，工程上必须做组合。

本文评述：这一局限与安全工程中的“纵深防御”原则一致（Saltzer & Schroeder, 1975）。笔者认为，把三条路线理解为“互斥选项”是误读，更准确的读法是“三种复杂度放置策略，可按任务风险分层组合”。例如：探索性任务用过程组织、写操作叠加边界约束、关键路径启用追加日志。组合的关键是明确每一层的职责边界，避免控制逻辑重复或冲突。

8.2 各自失效边界的具体表现

Claude Code 的失效边界：约定与实际代码脱节时，智能体会“自信地做错事”；多仓库场景下，约定难以统一；软约束无法用于合规举证。Codex 的失效边界：审批粒度过细导致吞吐下降；沙箱过窄导致任务无法完成（如需要联网查文档）；策略维护成为新的运维负担。DSH 的失效边界：插件接口设计不良导致隐式耦合；日志膨胀导致回放成本上升；架构复杂度对小团队不经济。

笔者认为，识别失效边界比识别优势更有决策价值。因为优势通常在演示中可见，而失效边界只在真实压力下暴露。一个实用的做法是：在选型阶段就为每条路线写下“我们预计它会在什么情况下失效”，并在试点中刻意构造这些情况。若团队无法承受该失效模式的后果，则应换路线或叠加补偿机制。

九、选型方法论：按“最怕什么失控”做决策

9.1 把风险画像转成决策变量

选型的第一步不是比较工具，而是把团队的风险画像写清楚。本文建议用四个问题做自评：其一，我们最怕的是“越界破坏”还是“过程不可控”还是“事后无法复盘”？其二，我们的任务以探索为主还是以批处理为主？其三，我们是否有专人维护策略或文档？其四，我们是否处于受监管环境、需要硬举证？这四个问题的答案，直接映射到 P/B/S 三维的权重。

下表给出一个可操作的映射（本文提出的决策矩阵）：

本文评述：这张矩阵的用法不是“对号入座”，而是“先确定第一恐惧，再检查叠加项是否可承受”。很多团队的错误是先选工具再找理由，结果在试点中不断为工具的弱项打补丁。更稳妥的顺序是：先写风险画像，再选主路线，再设计补偿层，最后才做工具评估。

9.2 一个反直觉的结论

按上述方法推演，会得到一个反直觉但经得起推敲的结论：对多数中小团队而言，最优解往往不是“选最强的那条路线”，而是“选维护成本与团队能力最匹配的那条”。原因在于，三条路线的收益都依赖持续投入才能兑现；若团队无力维护文档，Claude Code 的过程组织会退化为“一次性配置”；若无力维护策略，Codex 的边界会退化为“频繁误报”；若无力维护插件契约，DSH 会退化为“伪可拆卸”。笔者认为，这一结论比任何基准分数都更接近工程现实。

进一步地，团队可以把“维护能力”本身作为评估指标：过去一年是否有专人维护过类似文档/策略/接口？变更频率如何？事故复盘是否形成了闭环？若答案是否定的，那么无论选哪条路线，都应先补治理能力，再谈工具选型。这与组织工程能力成熟度模型的基本判断一致（Humphrey, 1989）。

十、落地路径：从评估到上线的六步操作法

10.1 六步法：可执行的操作清单

第一步，写风险画像。用 9.1 的四个问题做团队自评，形成一页纸结论，明确第一恐惧与可承受代价。第二步，选主路线。按决策矩阵选一条主路线，避免一开始就三线并进。第三步，设计补偿层。为主路线的弱项设计最小补偿，例如过程路线叠加只读沙箱、边界路线叠加会话日志。第四步，构造压力用例。刻意设计会触发失效边界的任务（越界写入、长任务漂移、插件替换），观察系统反应。第五步，量化四项指标。完成率、干预次数、上下文峰值、可恢复率，形成基线。第六步，建立维护节奏。为文档/策略/接口设定固定 review 周期，把治理成本制度化。

本文评述：这六步中最容易被跳过的是第四步和第六步。跳过第四步，试点会“顺利得可疑”，因为没人构造压力；跳过第六步，治理会在三个月内退化。笔者认为，把压力用例与维护节奏写进试点验收标准，是让选型结论真正落地的最有效手段。以下给出一个最小化的检查清单代码块，便于团队直接改用：

# 试点验收清单（示例）
risk_profile_written: true        # 风险画像一页纸
primary_route: "boundary"         # process | boundary | structural
compensation_layer: ["append_log"]
pressure_cases:
  - "越界写入尝试"
  - "长任务上下文漂移"
  - "插件热替换后回放"
metrics_baseline:
  completion_rate: 0.0
  human_interventions: 0
  context_peak: 0.0
  recoverability: 0.0
maintenance_cadence: "monthly"    # 文档/策略/接口 review 周期

10.2 组织层面的配套动作

技术路线落地离不开组织配套。本文建议三项动作：其一，指定控制面负责人。过程路线的负责人是文档维护者，边界路线的负责人是策略管理员，结构路线的负责人是接口治理者。没有明确负责人，治理必然退化。其二，把控制策略纳入变更管理。策略与文档的变更应走与代码相同的 review 流程，保留变更历史。其三，建立事故复盘模板。复盘时逐项核对 P/B/S 三维，判断是过程组织不足、边界缺失还是结构不可回放导致，从而形成改进闭环。

笔者认为，这三项动作的价值在于把“控制权”从抽象概念变成组织中的具体角色与流程。很多团队在工具层面投入很多，却在角色与流程上留白，结果工具能力无法转化为治理能力。这一判断与软件工程中“过程能力决定工具效用”的经典结论一致（Humphrey, 1989；Brooks, 1975）。

十一、结论与展望：三条路线的收敛与前沿预判

11.1 收敛趋势：三条路线正在互相吸收

观察 2025 年的产品演进，可以看到明显的收敛：过程组织型产品在补边界能力（更细的权限与审批），边界约束型产品在补过程能力（任务编排与上下文管理），可拆卸架构在补易用性（开箱即用的插件市场）。这一收敛的驱动力是用户需求：真实团队既怕越界，也怕跑飞，也怕无法复盘，单一维度的强保证不足以满足治理需求。本文评述：收敛并不意味着三条路线会合并为一条，而是意味着控制权配置将越来越像“可调参数”而非“产品标签”。

这一趋势对选型的含义是：不必过度担心“选错阵营”。更重要的是建立可迁移的治理能力——风险画像方法、压力用例库、指标基线、维护节奏。这些能力跨工具通用，是团队真正的资产。笔者认为，未来两年的竞争焦点将从“模型能力”转向“治理接口的开放程度”，即谁能把 P/B/S 三维的控制权以更细粒度、更可编程的方式暴露给团队。

11.2 前沿预判与可验证的观察点

基于现有证据，本文给出三个可验证的预判。预判一：审批机制将从“动作级”走向“意图级”，即系统不仅判断“这个命令是否危险”，还判断“这个命令是否符合当前任务意图”，从而降低误报。可观察信号是产品文档中是否出现意图描述字段。预判二：追加式日志将成为智能体平台的基础设施，类似可观测性中的 trace，成为跨厂商的通用概念。可观察信号是是否出现围绕智能体轨迹的开放格式与查询语言。预判三：过程组织将从“文档约定”走向“可执行契约”，即约定不仅是自然语言，还包含可校验的断言。可观察信号是是否出现针对智能体行为的静态检查工具。

本文评述：这三个预判都建立在“控制权可配置化”这一主线上，因而具备内在一致性。笔者认为，团队不必等待预判成真才行动；相反，可以现在就按 P/B/S 三维梳理自身治理现状，找出最薄弱的一维优先补强。无论工具如何演化，“先定义恐惧，再分配控制权”这一方法论都不会过时。回到文章标题的问题：同一项任务的控制权交给谁？答案不在工具对比表里，而在团队对自身失控恐惧的诚实评估里。

11.3 拓展资源

以下链接供进一步查阅（均在新窗口打开）：Anthropic：构建有效智能体、Claude Code 文档、OpenAI Codex 文档、Model Context Protocol、SWE-bench 官方站点、事件溯源（Fowler）、OpenTelemetry 文档、OWASP LLM 应用风险。

主要参考文献

说明：本文参考文献与资料总数为 62 篇（含上述 10 篇主要文献及正文提及的工程文档、评测说明与标准文档），其中 2022 年之后发表的文献占比约 56%。文中涉及的对照实验数据为模拟数据，已在对应位置标注；定性对照表为基于公开文档的整合分析，非同一实验条件下的定量测量。数据集方面，SWE-bench 使用真实 GitHub issue 与对应仓库快照，评测前需按官方脚本完成环境构建与测试用例筛选；本文未对原始数据做额外预处理，引用时请以官方发布版本为准。