Agents (Agent Engineering)

1. Introduction

1.1. Background: From "a model that chats" to "a set of orchestrated execution units"

Around 2023, the dominant industry form was "one model + one prompt." This form performs well in a single conversation, but once a task requires multi-step execution, calling external systems, interrupting and resuming, or multi-person collaboration, it exposes structural flaws: the model does not know "how far it has gotten," and there is no mechanism guaranteeing it "will not overreach."

After 2025, the form changed fundamentally. An agent is no longer another way of describing a prompt, but rather becomes a execution unit running on Harness: it has a clear loop structure (Agent Loop), dispatchable sub-units (Sub-agent), an explicit handoff protocol (Handoff), event hooks (Hooks) that can be intercepted by external systems, and a replayable trace (Trace).

The key significance of this change is that the agent itself has become an object that can be managed through engineering. Just as a process relates to an operating system — a process has a lifecycle, priority, resource quota, and termination signal; agents need the same.

1.2. Definition

Agents direction (Agent Engineering): an engineering field that studies and practices the structure, collaboration, handoff, termination, and control mechanisms of agents themselves. It does not focus on single-generation quality (that is the concern of the Coding and Eval directions), but rather on:

• how an agent's loop starts, advances, and decides to end;
• how multiple agents divide work, pass parameters, and avoid mutual context pollution;
• how external systems deterministically intercept or rewrite an agent's behavior at key nodes;
• how an agent saves state on failure, recovers, and avoids repeating already-completed side effects.

According to the project parameter card, an Agent is a execution unit running on Harness; Harness is the Agent's "chassis." This direction discusses precisely the control plane of this chassis.

1.3. Position within the AI Harness System

图 1-1｜Agents 在 Harness 六层体系中的定位

数据来源：基于本文分析绘制的示意图。

This direction spans the six layers of Harness; the primary layer is the L3 Orchestration and Control Layer, with secondary layers of L2 Tools and Execution Layer and L6 Governance and Security Layer.

1.4. Bottleneck Layer

The bottleneck of this direction is not in model capability, but in the L3 Orchestration and Control Layer, manifesting as three structural problems:

1. Loop non-convergence. When an agent lacks a clear termination decision, it oscillates between "try again" and "try another approach," consuming the entire budget with no substantive progress. DORA 2025 (2025-11-12) shows that 30% of AI tasks take more than 4 hours per run — this figure indirectly reflects the absence of control mechanisms in long-horizon tasks.
2. Mutual context pollution. When multiple sub-agents share the same context, the intermediate process of any unit (mistaken attempts, discarded plans) pollutes the judgment of other units; full isolation in turn causes shared constraints to be lost.
3. Control depends on the model's self-awareness. Writing "do not delete files" and "do not force push" into the prompt amounts to building the security boundary on the model's memory and will. This is unreliable: constraints must be deterministic and executable by external systems.

The solution to the third difficulty is precisely the most important engineering progress of this direction in recent years: use event hooks (Hooks) to turn control from "a prompt" into "a mechanism".

1.5. Value

• Converge uncertainty into an enumerable state machine. The agent's behavior space changes from "infinite" to "finite states + finite transitions" — the precondition for testability and auditability.
• Make the security boundary executable. Constraints that rely on prompts are suggestions; constraints that rely on hooks are rules.
• Make failures recoverable. For an agent with checkpoints, failure loses time, not the entire progress.
• Make collaboration a division of labor. The value of multi-agent is not "many models thinking together," but parallelism + isolation + aggregation — cutting a large task into non-interfering write partitions, then merging the results once each is complete.

2. Glossary

3. Case Studies

Note: The following cases are compiled from verifiable primary public sources. The effect figures in the cases follow the stated figures of their sources; when citing, the evaluation date and configuration must be noted together.

3.1. Case 1: Multi-agent orchestration driven by event hooks

Source: Anthropic, Claude Code official documentation (Hooks section), https://docs.claude.com/en/docs/claude-code/hooks

3.1.1. Background

Early agent products wrote security and process constraints into system prompts. Engineering practice exposed three kinds of problems: constraints are squeezed out by context compaction in long tasks; the model rationalizes out-of-bounds behavior under "pressure to complete the task"; and the same kinds of constraints must be repeatedly written at multiple entry points, leading to clause drift.

3.1.2. Approach

Move the control points from "within the prompt" to "on lifecycle events", forming a deterministic event—policy table. The core design is as follows:

Table 3-1　Agent lifecycle event table (nine types of events)

Table 3-2　Hook exit-code semantics (typical convention)

The semantics of exit code 2 are a key design of this direction: it turns "no" from a request at the language level into a fact at the system level. The model can try again, but it cannot bypass it.

Table 3-3　Priority and the nearest-first principle

The priority of instructions and control policies, from highest to lowest, is:

3.1.3. Results

• Safety constraints change from "a prompt" to "a mechanism": interception of dangerous commands no longer relies on the model's memory, but is deterministically blocked by hooks before a tool executes.
• Constraints no longer get lost in long tasks: the PreCompact event archives key clauses before compaction; SessionStart re-injects them at each session.
• Completeness can be forcibly validated: the Stop hook can check "whether tests ran" and "whether evidence is complete", blocking the end if unsatisfied.
• This pattern has been adopted by several agent products and has become one of the hallmark features of the third-generation Harness (the runtime and evaluation era).

3.2. Case 2: In-enterprise multi-agent R&D pipeline

Source: Alibaba Group public technical practice (2025-09); Tencent CodeBuddy public practice (2025-08)

3.2.1. Background

The pain point of large R&D organizations is not "whether code can be generated", but consistency across repositories, languages, and teams: a single requirement often touches frontend, backend, configuration, and tests at the same time; a single-point agent struggles to cover it all, and the generated results must satisfy the organization's framework conventions, naming standards, and security baseline.

3.2.2. Approach

A layered structure of "orchestrator + dedicated sub-agents" is adopted:

• Orchestrator: responsible for requirement decomposition, task dispatch, dependency sorting, and result aggregation; it does not write business code itself.
• Dedicated sub-agents: partitioned by responsibility (requirements analysis, coding, test generation, code review, documentation); each type of sub-agent has an independent context window and a minimized tool subset.
• Write partitions: parallel sub-agents divide mutually exclusive write ranges by module, prohibiting concurrent writes to the same file.
• Handoff contracts: sub-agents do not share the full context, passing only structured artifacts (change lists, interface signatures, test results) and constraint summaries.
• Organization-convention injection: framework conventions, naming standards, and security baseline are injected into each layer through layered instruction files, with nearest-first overriding.
• Human confirmation points moved forward: confirm the decomposition plan and blast radius before dispatch, rather than reviewing only after everything is complete.

3.2.3. Results

Among the public quantitative results, Tencent CodeBuddy's practice (2025-08) shows Code Review time reduced by 80%+. Alibaba's internal practice published in 2025-09 likewise points to "R&D-process-level integration" rather than "single-point efficiency gains".

It must be emphasized that the above figures are the vendors' self-reported figures. When deploying in an enterprise, internal metrics should be established (see 05-eval.md), and conclusions should be based on end-to-end metrics rather than per-stage timings — because a speedup in one stage may be offset by increased cost in downstream stages (see the "self-report vs. measurement divergence" discussion in 3.3 and 05-eval).

3.3. Case 3: The capability boundary of agents for long-horizon terminal tasks

Source: Terminal-Bench 2.0 official leaderboard, https://www.tbench.ai/

3.3.1. Background

Terminal-Bench is a class of agent benchmark oriented toward long-horizon terminal-operation tasks: the agent must complete tasks such as system configuration, troubleshooting, and environment setup in a real terminal environment through dozens to hundreds of commands. Unlike "writing code", each step of such tasks may change the system state and is irreversible.

3.3.2. Approach (evaluation design perspective)

Terminal-Bench 2.0's design reflects three key control requirements of this direction:

• Step and time budget: tasks complete within a limited number of steps, examining the agent's planning efficiency rather than its exhaustive capability.
• Determinable state: each task has a clear pass/fail decision (usually a set of assertion scripts), avoiding subjective scoring.
• Environment isolation: each round runs in a clean environment, preventing the previous round's state from polluting the next — precisely the engineering requirement that "agent side effects must be isolatable".

3.3.3. Results

Interpretation: Even at the best public result, nearly half of the long-horizon terminal tasks still fail. This shows that the bottleneck of this direction is indeed not "whether the model is smart enough", but the control mechanism — how to plan, how to stop losses, and how to stop before an irreversible operation. The full leaderboard figures and finer-grained sub-scores of Terminal-Bench 2.0 are marked as [To be verified].

4. Practice Standards

4.1. AGENTS.md Specifications

The following is the complete AGENTS.md text for this direction, placed in a code block for direct copying. When using it, the common clauses of the group-level AGENTS.md must be applied on top; when conflicts arise, resolve them by the nearest-first principle.

# AGENTS.md —— 软件工程 · Agents 方向（智能体工程化）

## 角色与边界

- 本文件约束**构建与运行智能体系统**的工作：Agent Loop 设计、Sub-agent 定义、Handoff 协议、Hooks 配置、编排器实现、智能体运行时改造。
- 允许自行完成：设计循环结构、定义子智能体契约、配置事件钩子、实现终止条件、编写 Handoff 数据结构、构造 Trace 采集点、设置预算护栏。
- 禁止自行完成：为智能体授予共享状态写权限（S 级）或破坏性权限（D 级）、关闭或绕过已有的拦截钩子、修改审计配置、删除 Trace。
- 边界判定：凡改变**智能体可执行动作集合**的改动，一律视为安全相关变更，须走人工评审。

## 环境假设

- 提供智能体运行时（Agent Runtime），支持：循环控制、子智能体派发、事件钩子注册、检查点保存与恢复。
- 提供容器或微虚机沙箱，智能体的一切命令执行均在沙箱内完成。
- 提供 Trace 采集与存储，保证全过程可回放。
- 提供成本与步数计量，且支持设置硬上限。
- 提供工具注册中心，每个工具有机器可读的副作用分级声明。
- 缺失任一项时，降级执行并在任务开始时声明缺失项与风险。

## 上下文加载顺序（Context Budget）

1. 任务契约：目标、产出物、验收标准（固定，不压缩）
2. 就近指令文件：当前目录及其祖先链
3. 运行时现状清单：已有的子智能体定义、钩子配置、工具注册表
4. 相关实现源码：循环、派发、钩子处理逻辑
5. 测试与仿真：智能体行为的测试用例与仿真脚本
6. 历史事故记录：循环不收敛、越权、上下文污染事件
7. 工具结果：按需追加

每一步记入 Token 预算表；超限执行压缩而非截断，压缩前须经 PreCompact 归档关键约束。

## 工具契约

- 所有工具必须有声明：名称、参数模式、副作用级别（R/W/X/S/D）、幂等性、超时、输出体积上限。无声明工具不得注册。
- 子智能体的工具集必须是父级工具集的**子集**，遵循最小权限。
- S 级与 D 级工具默认不在任何子智能体中启用；确需时须在契约中逐项列出并说明必要性。
- 所有执行类工具必须设置超时；超时即失败，进入失败处理流程。
- 输出超过约定行数时必须截断并给出定位信息（路径 + 行号区间）。

## 任务执行流程（SOP）

1. 解析任务契约，明确产出物与验收标准；契约缺失则停止并澄清。
2. 绘制控制流图：状态、转移、终止条件、异常处理分支。
3. 确定子智能体切分方案与写分区边界。
4. 定义 Handoff 契约：传递字段、类型、必填性、失败语义。
5. 设计事件钩子表：事件、触发条件、判定逻辑、退出码语义。
6. 设定预算护栏：步数上限、Token 上限、时长上限、重试上限。
7. 实现后用仿真脚本验证控制流（含终止条件可达性测试）。
8. 输出配置与说明，进入人工评审。

## 验证与证据要求

必须通过以下验证并留存证据：

| 验证项 | 判定方式 | 证据 |
|---|---|---|
| 终止条件可达 | 遍历状态图，存在从任一状态到终止态的路径 | 状态图 + 可达性分析结论 |
| 循环有界 | 步数上限存在且可被运行时强制执行 | 配置 + 超限触发测试记录 |
| 上下文隔离有效 | 子智能体之间不共享完整上下文 | 隔离测试：一个子单元注入噪声，另一单元不受影响 |
| 拦截确定 | 危险动作被钩子阻断，模型无法绕过 | 拦截测试：每种 D 级动作至少一次实测拦截 |
| 检查点可恢复 | 中断后从检查点恢复，不重复已完成副作用 | 恢复测试：中断—恢复—比对副作用次数 |
| Trace 完整 | 全过程工具调用可回放 | Trace 样本 + 回放校验 |
| 预算生效 | 超限时中断并升级 | 超限测试记录 |
| 并行无写冲突 | 并发子智能体不写同一文件 | 并发测试记录 |

禁止以"逻辑上应该没问题"作为验证结论；禁止用修改断言的方式让验证通过。

## 失败与升级策略

| 失败 | 处理 |
|---|---|
| 循环不收敛（步数超预算且无进展） | 强制终止，保存检查点，输出进展与卡点，上报 |
| 越权被拦截 | 不得绕过；记录意图与命令，转入人工升级 |
| 子智能体产出不合格 | 由 SubagentStop 钩子判定为不合格并要求继续；超过重试上限则终止并上报 |
| 恢复后副作用重复 | 判定检查点设计缺陷，回滚并修复；禁止以去重脚本掩盖 |
| 契约冲突（Handoff 字段不一致） | 停止派发，上报冲突点 |

升级三要素：已尝试动作与结果、卡点现象与证据、建议选项及风险。缺一无效。

## 安全与合规红线

1. 禁止为智能体授予 D 级（破坏性/不可逆）权限；确需时须逐命令人工确认并留痕。
2. 禁止关闭、绕过、或降低已有拦截钩子的严格程度；钩子变更须走安全评审。
3. 禁止子智能体继承父级全部权限；权限必须显式最小化授予。
4. 禁止删除、篡改、压缩 Trace 与审计日志。
5. 禁止在指令文件、配置、日志中写入密钥、Token 与个人信息。
6. 遵循 OWASP Agentic AI 威胁与缓解清单（T&C，2025-12-09；V1.0，2026-03-16），重点防范目标劫持、工具滥用、身份与权限混淆、记忆投毒。
7. 遵循 OWASP Top 10 MCP（2025-12-07），对工具服务端做来源审查与权限最小化。
8. 组织级落地对齐 ISO/IEC 42001:2023 的角色职责与成文信息要求。

## 禁止事项

1. 禁止把安全约束只写在提示词里而不用钩子做硬拦截。
2. 禁止设计无终止条件的循环。
3. 禁止让多个子智能体并发写同一文件而不做写分区。
4. 禁止在检查点中遗漏工具副作用记录。
5. 禁止一次性请求过宽权限。
6. 禁止以"模型认为"作为技术判断依据。
7. 禁止使用 `[待填写]`、`XX`、`___` 之外的非标准占位符；不确定处统一使用 `[待填写]`。

## 输出格式

- 控制流图（状态与转移的文字化描述或图）
- 子智能体清单：名称、职责、工具子集、上下文范围、写分区
- Handoff 契约：字段名、类型、必填、失败语义
- 事件钩子表：事件、触发条件、判定逻辑、退出码语义
- 预算配置：步数、Token、时长、重试上限
- 验证记录：八项验证的逐项结果
- 变更说明五段：改了什么 / 为什么 / 如何验证 / 风险 / 如何回滚

## 评估与自检

| 自检项 | 判定 |
|---|---|
| 终止条件是否明确且可达 | 是 / 否 |
| 循环是否有硬边界 | 是 / 否 |
| 子智能体上下文是否隔离 | 是 / 否 |
| 危险动作是否由钩子硬拦截 | 是 / 否 |
| 检查点是否可恢复且不重复副作用 | 是 / 否 |
| Trace 是否完整可回放 | 是 / 否 |
| 预算护栏是否生效 | 是 / 否 |
| 并行写分区是否互斥 | 是 / 否 |

任一"否"须显式列出；自检不通过即任务未完成。

4.2. SKILL.md Specifications

---
name: multi-agent-orchestration-setup
description: 设计与落地一套多智能体编排系统：拆解任务、切分子智能体与写分区、定义 Handoff 契约、配置事件钩子与退出码语义、设定预算护栏与终止条件，并通过八项控制流验证。当需要让多个智能体协作完成一项工程任务，或为既有智能体系统补足控制面时使用。
version: 1.0
created: 2026-09-12
---

# 多智能体编排系统搭建

## 适用场景

- 单个智能体无法在预算内完成的大任务，需要拆解与并行。
- 任务可按模块/文件/职责切分，且各部分的写入范围互不重叠。
- 需要为既有智能体系统补足控制面：终止条件、拦截钩子、检查点、预算护栏。
- 需要把"不要做某事"从提示词升级为确定性机制。

不适用于：单步任务、无法切分的整体性创作、无判定标准的开放式探索。

## 前置条件

| 类别 | 要求 | 缺失时处置 |
|---|---|---|
| 任务契约 | 目标、产出物、验收标准明确 | 停止，先补全契约 |
| 运行时 | 支持子智能体派发与事件钩子注册 | 降级为单智能体 + 外部脚本控制 |
| 沙箱 | 命令执行在容器或微虚机内 | 禁止执行，升级 |
| 工具注册 | 工具有副作用分级声明 | 先补齐声明 |
| Trace | 工具调用与文件变更可完整记录 | 降级执行并声明"不可回放" |
| 计量 | 步数/Token/时长可设上限 | 设定保守默认上限 |

## 输入

- 任务描述与验收标准
- 仓库或系统的模块边界
- 可用工具清单及其副作用分级
- 预算上限（步数 / Token / 时长）
- 现有智能体与钩子配置（如为改造任务）

## 输出

- 控制流图（状态、转移、终止条件、异常分支）
- 子智能体清单（职责、工具子集、上下文范围、写分区）
- Handoff 契约（字段、类型、必填、失败语义）
- 事件钩子表（事件、触发条件、判定逻辑、退出码语义）
- 预算与护栏配置
- 八项控制流验证记录
- 五段式变更说明

## 执行步骤

1. **拆解**：按写分区而非按"思考角色"切分任务。判断标准是"两部分的写入范围是否重叠"——重叠则不得并行。
2. **定义子智能体**：为每个分区设定职责、工具子集（父级子集）、上下文范围（仅含本分区必要信息）。
3. **设计 Handoff 契约**：只传结构化产物与约束摘要，不传完整上下文。字段须有类型与失败语义。
4. **配置事件钩子**：至少覆盖 `PreToolUse`（拦截）、`PostToolUse`（校验）、`Stop`（完成度）、`SubagentStop`（子单元质量）。明确退出码 2 为阻断语义。
5. **设定终止条件**：必须写成可检查的断言（如"测试命令退出码为 0 且失败数为 0"），不得写成"任务看起来完成了"。
6. **设定预算护栏**：步数、Token、时长、重试上限，且由运行时强制执行。
7. **设计检查点**：在每个不可逆动作之前保存，检查点须记录已产生的副作用清单。
8. **仿真验证**：用脚本跑通八项验证（终止可达、循环有界、隔离有效、拦截确定、恢复无重复、Trace 完整、预算生效、并行无冲突）。
9. **交付**：输出配置、说明与验证记录，进入人工评审。

## 质量标准（DoD）

1. 终止条件明确、可检查、可达。
2. 循环存在运行时强制的硬边界，超限即中断。
3. 子智能体上下文隔离，且工具集为父级子集。
4. 每一类 D 级动作都有实测通过的拦截记录。
5. 检查点可恢复，恢复后不重复任何已完成的副作用。
6. Trace 完整且可回放。
7. 并行写分区互斥，无并发写同一文件。
8. 预算护栏在实测中确实触发中断。
9. 未触及权限与安全红线。
10. 变更说明五段齐全，回滚方案不依赖智能体继续参与。

## 常见失败与处理

| 失败 | 表现 | 处理 |
|---|---|---|
| 循环不收敛 | 步数耗尽无实质进展 | 强制终止 + 保存检查点 + 上报卡点 |
| 上下文污染 | 子单元引入无关信息影响判断 | 收紧 Handoff 字段，只传结构化产物 |
| 越权尝试 | 试图执行 D 级操作 | 不得绕过；记录并升级 |
| 拦截失效 | 钩子未触发或被绕过 | 判定为阻断性缺陷，回滚 |
| 恢复后重复副作用 | 非幂等动作被重放 | 修复检查点记录，禁止用去重脚本掩盖 |
| 写冲突 | 两子单元改同一文件 | 重新划分写分区或改为串行 |
| 终止条件不可达 | 断言永远为假 | 修正断言，或增加"最大努力后上报"的兜底分支 |

## 示例

**场景**：为一个 12 万行的单体仓库做"模块 A 的接口迁移"，涉及 40 个调用点。

- 切分：按目录划分 5 个写分区，每区 8 个调用点；交叉引用点单独列为串行区。
- 子智能体：5 个迁移单元（工具集 = 读文件 + 编辑 + 构建/测试，无 git push），1 个汇总单元。
- Handoff：传 `{file, oldSymbol, newSymbol, verified: bool, testCmd, exitCode}`。
- 钩子：`PreToolUse` 拦截任何 `git push` / `rm -rf` / `git checkout --`（退出码 2）；`Stop` 校验"全量测试已执行且失败数为 0"。
- 预算：单区步数上限 60，全局 Token 上限按团队默认。
- 验证：八项全过；其中拦截测试逐一实测 3 类危险命令均被阻断。
- 交付：变更集 40 个文件，每文件一句话说明；回滚为 `git revert` 单个合并提交。

4.3. Landing Checklist

Design Phase

• [ ] Control-flow diagram has been drawn; states and transitions are complete, with no isolated states
• [ ] The termination condition is a checkable assertion, not a subjective description
• [ ] A path from any state to a termination state has been proven to exist
• [ ] The loop has a runtime-enforced hard step cap
• [ ] Sub-agent partitioning is based on write partitions rather than "thinking roles"
• [ ] Write partitions do not overlap; intersecting parts have been identified and set as serial
• [ ] Handoff contract fields are clear: name, type, required/optional, failure semantics
• [ ] Handoff passes only structured artifacts and constraint summaries, not the full context

Control and Interception

• [ ] PreToolUse covers all D-level actions, and the exit-code-2 semantics are unified across the team
• [ ] PostToolUse is used for result validation and output-size trimming
• [ ] Stop / SubagentStop are used for completeness and output-quality validation
• [ ] PreCompact is used to archive key constraints and prevent loss during compaction
• [ ] SessionStart / SessionEnd are used for context injection and Trace archiving
• [ ] Every kind of dangerous action has a verified-passing interception record (not "it should intercept")
• [ ] Permissions are granted on a least-privilege basis; sub-agent tool sets are subsets of the parent

State and Recovery

• [ ] There is a checkpoint before every irreversible action
• [ ] Checkpoints record the list of side effects already produced
• [ ] Recovery test passes: after interruption—recovery, the side-effect count matches expectations (no duplicates)
• [ ] Session state and artifact storage are separated; artifacts carry version identifiers

Observability and Metrics

• [ ] Trace fully records tool calls, file changes, and command-output summaries
• [ ] Trace is replayable and has actually been replayed and validated once
• [ ] Steps / tokens / time / retry counts are all metered and capped
• [ ] Exceeding the limit is actually tested to trigger interruption and escalation (not merely that the configuration exists)
• [ ] Loop non-convergence has independent detection and alerting

Compliance and Review

• [ ] No permission or security red lines have been crossed
• [ ] Trace and audit logs cannot be deleted or tampered with by agents
• [ ] Changes involving permission changes have gone through human review with an audit trail
• [ ] Mitigations from OWASP Agentic AI and OWASP Top 10 MCP have been aligned
• [ ] The five-part change description is complete, and the rollback plan is executable without depending on the agent

5. Summary

The Agents direction answers a seemingly simple yet decisive question: once a model is given the ability to act, who controls it?

This direction has three core conclusions:

1. The bottleneck lies in the L3 Orchestration and Control Layer, not the model capability layer. The best public score on Terminal-Bench 2.0 (GPT-5.2, 54.0%, 2025-12-11) means that nearly half of long-horizon tasks still fail. Most failures are not because "no approach could be found", but because planning failed, loss-stopping failed, or it did not stop before an irreversible operation.
2. Constraints must be mechanisms, not prompts. Writing the security boundary into a prompt means entrusting security to the model's memory and will. Event hooks (Hooks) + blocking exit codes (exit code 2) turn "no" from a language request into a system fact; this is the most critical engineering progress of the third-generation Harness.
3. The value of multi-agent lies in isolation, not brainstorming. The premise of parallelism is mutually exclusive write partitions; the premise of collaboration is explicit Handoff contracts; the premise of recovery is checkpoints recording side effects. Without these three, "multi-agent" only parallelizes errors.

The recommendation for teams deploying this is: build the control plane first, then talk about the capability plane. Until the three things — termination conditions, interception hooks, and checkpoints — are done, any judgment about "how powerful our agent is" is unreliable.

Information Gap Declaration

1. The complete configuration-option list for event hooks (including option names, values, and defaults) could not be verified item by item at the time of writing; the official documentation describes them as a set of configuration items. The specific values follow the official documentation of the product in use. This document only provides the already-verified parts such as the event table and exit-code semantics.
2. The full leaderboard figures and sub-score details of Terminal-Bench 2.0 are marked as [To be verified].
3. The vendor practice figures in Case 3.2 are self-reported and lack third-party reproduction; when citing, the "self-reported" attribute must be noted and they must not be mixed with measured data.
4. Some enterprise-case details and source URLs of this direction await backfilling after the retrieval report is supplemented.

6. References

1. Claude Code Docs · Hooks (event table and exit-code semantics) — Anthropic. https://docs.claude.com/en/docs/claude-code/hooks
2. Claude Code Docs · Sub-agents — Anthropic. https://docs.claude.com/en/docs/claude-code/sub-agents
3. Claude Code Docs · Memory (CLAUDE.md configuration location and @import) — Anthropic. https://docs.claude.com/en/docs/claude-code/memory
4. AGENTS.md official site — Linux Foundation / Agentic AI Foundation, 2025-12-09. https://agents.md/
5. Model Context Protocol official specification — Anthropic and others. https://modelcontextprotocol.io/
6. Terminal-Bench official leaderboard — Laude Institute and others. https://www.tbench.ai/
7. OWASP Agentic AI Threats and Mitigations (T&C, 2025-12-09; V1.0, 2026-03-16) — OWASP. https://genai.owasp.org/
8. OWASP Top 10 for MCP — OWASP, 2025-12-07. https://genai.owasp.org/resource/agentic-ai-top-10/
9. OWASP Top 10 for LLM Applications 2025 — OWASP, 2025-11-10. https://owasp.org/www-project-top-10-for-large-language-model-applications/
10. ISO/IEC 42001:2023 AI management systems — ISO/IEC, 2023. https://www.iso.org/standard/42001
11. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025-11-12. https://dora.dev/research/2025/dora-report/
12. Anthropic Engineering Blog · Building effective agents — Anthropic. https://www.anthropic.com/research/building-effective-agents