AI Agent 系统性知识体系

这不是入门课程、项目教程或简历准备，而是一套用于理解、分析和判断 AI Agent 系统的知识坐标系。研究基线：2026-08-03。

本文件是全局总纲，不再承担每一层的全部细节。精确定义、状态机、设计分支、故障矩阵、评测方法、最新证据和面试深追问统一进入 十四卷深度专题。

本体系使用两个正交轴：provenance / 可验证性回答“这项陈述凭什么成立”，frontier capability / 先进性回答“该系统在真实任务上把能力边界推进到了哪里”。公开源码可以使机制高度可审计，却不自动代表能力领先；闭源产品可以处于能力前沿，但未公开后端只能标为产品事实、推断或未知，不能用品牌或官方口径补全。

0. 这套体系解决什么问题

Agent 行业的常见问题不是信息太少，而是知识散乱：模型、workflow、memory、MCP、multi-agent、sandbox、evaluation 被当成彼此独立的热点。真正需要建立的是稳定的底层结构，使任何新模型、框架、论文或产品都能被放回同一坐标系中判断。

这套体系围绕四个目标：

1. 定义对象：Agent 系统究竟由哪些不同对象组成；
2. 解释机制：能力、可靠性、成本和风险从哪里产生；
3. 判断边界：什么应该交给模型，什么必须由确定性系统拥有；
4. 吸收变化：行业变化时更新局部事实，而不推翻整体认知结构。

1. 第一原则：Agent 是什么

深度卷：第一原则、本体与全局架构。

1.1 最小定义

Agent 是一个在部分可观测环境中，围绕目标持续执行“观察—决策—行动—反馈”的系统。它必须同时拥有：

• Goal：需要改变的外部状态；
• Policy：根据当前信息选择下一行动的机制；
• State：跨步骤保留的任务、环境和决策状态；
• Action：对外部世界产生读取或副作用的能力；
• Feedback：判断行动结果和目标差距的证据；
• Boundary：权限、资源、时间、成本和风险约束。

LLM 可以承担 policy 的重要部分，但不等于整个 Agent。一个更准确的表达是：

Agent System
  = Model Policy
  + Control Harness
  + Context/State
  + Tools/Environment
  + Verification
  + Trust Boundary
  + Human Interface

1.2 Coding Agent 的特殊性

Coding Agent 面对的是一种高结构、高副作用、可部分验证但环境极其异构的任务：

• 状态分布在源码、Git、依赖、进程、服务、数据库和人的决定中；
• 正确性不仅是代码语义，还包括构建、测试、运行行为、架构约束与用户意图；
• 行动有真实副作用，且取消不一定能回滚；
• 任务跨度可从单行修复延伸到数小时、多环境、多角色协作；
• 环境中的文本既是知识，也是潜在的不可信指令；
• 模型能力、harness 和工具设计会相互塑造最终表现。

因此 Coding Agent 本质上是：以 LLM 为概率决策器、以软件工程环境为行动空间、以外部证据定义完成的可靠执行系统。

1.3 三个嵌套闭环

Step loop：观察 -> 推理 -> 工具 -> 新观察
Task loop：目标 -> 计划/执行 -> 验证 -> 完成或重规划
Learning loop：线上 trace -> 失败归因 -> eval -> 模型/harness 改进 -> rollout

大量讨论只覆盖第一个循环。真正成熟的 Agent 产品必须同时拥有三个循环。

1.4 五种时间尺度

不同时间尺度有不同状态和所有者。把它们都塞进 messages[] 是许多架构问题的源头。

2. 核心本体：Agent 世界里有哪些对象

2.1 对象关系

User Intent
  -> Goal + Constraints + Success Criteria
      -> Turn
          -> Step
              -> Context Snapshot
              -> Model Decision
              -> Tool Intent
                  -> Effect
                  -> Receipt / Observation
              -> Verification Evidence
      -> Outcome

Journal records facts
Trace explains causality
Transcript presents interaction
Telemetry measures populations
Memory carries validated knowledge across scopes

2.2 必须严格区分的对象

2.3 六个核心不变量

1. 模型输出不是外部事实：行动是否发生必须由环境或 receipt 证明。
2. 完成不是语言行为：任务完成由 success criteria 和 verifier 决定。
3. 取消不是回滚：已经发生的副作用必须独立核对。
4. 状态必须有所有者：UI、模型 context 和日志不能同时自称事实源。
5. 约束不能静默降级：容量不足、权限拒绝或验证缺失必须显式呈现。
6. 恢复不能等于重放：未知副作用状态先 reconciliation，再决定是否重试。

3. 全局架构：十个知识层

10. Economics & Product Strategy
 9. Human-Agent Interaction
 8. Safety, Trust & Governance
 7. Evaluation, Data & Learning
 6. Coordination & Multi-Agent
 5. Protocols & Extension Ecosystem
 4. Runtime & Distributed Systems
 3. Tools & Environment
 2. Context, State & Memory
 1. Model & Inference

Cross-cutting Control Plane：Loop / Planning / Policy / Verification

这不是严格的调用栈，而是分析栈。任何产品能力通常穿过多层。例如“长任务续跑”同时涉及模型注意力、compaction、任务状态、journal、worker lifecycle、交互和评测。

4. 第一层：Model 与 Inference

深度卷：Model、Inference 与 Agentic Training。

核心问题

• 模型能够基于什么输入做出哪类决策？
• 模型原生能力与 harness 补偿分别是什么？
• 模型特性如何改变系统架构，而不只是 benchmark？

知识结构

4.1 输入与表示

• tokenization 与实际 context 成本；
• system/developer/user/tool 等角色与 authority；
• text/image/audio 等多模态表示；
• tool schema、structured output 和 grammar constraint；
• 长上下文中的位置、相关性、重复和 context rot。

4.2 推理与控制参数

• reasoning effort / thinking budget；
• temperature、sampling 与任务方差；
• max output/context budget；
• parallel tool calls；
• preserved reasoning 或跨 turn thinking continuity；
• prompt caching 与 exact prefix。

4.3 Streaming Protocol

• text delta、reasoning delta、tool-call delta；
• tool call ID 与 result adjacency；
• finish reason；
• usage、trace ID 与 provider metadata；
• 半包、断流、重复 event 和重连。

4.4 Provider 异构

“兼容 API”只统一表面字段。实际差异包括：

• context 与 output limit；
• thinking 的表示和续接；
• tool ID 约束；
• schema 支持范围；
• media 大小与格式；
• error taxonomy；
• prompt cache；
• rate limit、quota 和 region；
• data retention 与隐私政策。

4.5 Agentic Post-training：训练对象已经从答案变成轨迹

传统指令微调主要学习“给定输入生成答案”；Agentic post-training 学的是在环境反馈下跨多轮选择动作。训练单元因此从 answer pair 扩展为 trajectory：

task + environment snapshot
  -> observation
  -> reasoning / action
  -> tool result
  -> state transition
  -> verifier reward

核心难题也随之变化：

• environment stability：依赖、网络或工具不稳定会把噪声写进 policy；
• credit assignment：长轨迹最后成功，哪些早期决定真正有贡献；
• reward hacking：模型绕过 verifier，而不是真正完成任务；
• trajectory fidelity：训练时 tool protocol 与生产 harness 是否一致；
• sampling economics：长轨迹的 sandbox、tokens 和 wall time 成本；
• off-policy drift：harness 或工具变化使旧 trajectory 失真；
• failure data：失败轨迹应提取可迁移反事实，而不是原样模仿。

2026 年出现了两个互补方向：

1. ToolVerse把近 400 个 MCP、约 4,500 个工具转成可执行 RL 环境，并用 tool dependency graph 构造长任务；
2. Polar把现有 Codex、Claude Code、Qwen Code 等 harness 当黑盒采集 token-faithful trajectory，表明生产 harness 本身正在进入训练闭环。Polar 在论文中明确说明它重写并取代前作 ProRL Agent，因此两者是同一研究谱系的前后版本，不能当成两次独立复现。

这使“模型团队”和“Agent Infra 团队”的边界发生变化：前者需要生产级环境与轨迹，后者必须保证 tool/state/trace contract 足够稳定，才能让训练信号有意义。

4.6 三种 Test-time Scaling

三者并非可互换。Depth 依赖可靠反馈，width 依赖独立性与 evaluator，experience 依赖 memory provenance。Google 的 ReasoningBank进一步把 parallel/sequential test-time scaling 的探索结果蒸馏进 reasoning memory，形成“计算产生经验，经验再改善计算”的闭环。

4.7 K3 暴露出的模型—Harness 联合事实

K3 技术报告没有把 agentic benchmark 当成纯模型分数：不同模型使用不同 harness，K3 在 DeepSWE、Terminal-Bench、Kimi Code Bench 等任务上使用 Kimi Code；Kimi Code Bench 2.0 还披露 K3 在 Kimi Code 与 Claude Code harness 下得到不同结果。BrowseComp 则明确报告 300K token 触发 compaction 的结果，并对比 1M 原始 context 无管理的结果。

这说明三个判断：

• 模型报告已经无法回避 harness disclosure；
• 1M context 与 compaction 不是二选一；
• refusal、fallback、effort、temperature、turn limit 和硬件环境都属于 agentic result contract。

参考：Kimi K3 技术报告与完整评测说明。

典型失败

• tool arguments 截断后仍被执行；
• stable prefix 被动态时间、随机 tool ordering 破坏；
• context 足够大但信号密度下降；
• quota error 被当 transient 无限 retry；
• provider adapter 用最低公分母抹掉关键能力；
• 模型升级后旧 prompt scaffolding 反而束缚能力。

2026 前沿判断

模型与 harness 正在协同设计：模型越来越原生地学习工具、长任务、compaction 和多模态软件环境；harness 同时成为 inference runtime、训练环境与评测变量。它的长期价值将从“教模型怎么做”转向“定义状态、环境、证据和安全边界”。好的 scaffolding 应随模型增强而可被消融和删除，而稳定的 effect、state、trace、verifier contract 会越来越重要。

5. 第二层：Context、State 与 Memory

深度卷：Context、State 与 Memory。

三者经常被混为“上下文”，但解决不同时间尺度的问题。

5.1 Context

当前一次模型请求能够看到的证据集合。主要问题是选择、组织、预算、顺序和 provenance。

Authority / policy
Goal / constraints / decisions
Current task state
Repository evidence
Recent trajectory and failures
Tool capabilities
Relevant memory

核心原则不是最大 context，而是 smallest sufficient context。

5.2 State

系统对任务和环境的持久认知，包括 goal、todo、decisions、tool effects、verification 和 lifecycle。State 必须独立于模型当前是否“记得”。

状态形态：

• ephemeral in-step state；
• turn/session state；
• durable journal；
• derived projection；
• external environment state；
• distributed worker/lease state。

5.3 Memory

跨 turn、session、project 或用户范围保存的经治理知识。

Memory item 应带 scope、provenance、confidence、version、TTL、invalidation 和验证状态。

5.4 Repository Context Engineering

lexical/path/name
  + symbol/reference
  + dependency/build/test graph
  + git history/diff/blame
  + semantic retrieval
  -> evidence expansion
  -> rerank
  -> token-budgeted context

Lexical 适合精确标识符、错误文本、配置键；symbol/graph 适合控制路径；semantic 适合概念相似但命名未知。成熟系统是混合检索，不是 embedding 单栈。

Context acquisition 应被单独评测

端到端 patch success 会把“是否找到正确代码”和“找到后能否正确修改”混在一起。2026 年的评测开始把 repository exploration 独立出来：

• SWE-Explore覆盖 848 个 issue、10 种语言、203 个仓库，在固定 line budget 下评估 coverage、ranking 和 context efficiency；结果显示 file-level localization 已较强，line-level coverage 与高效排序仍是主要差距；
• Agent Retrieval Bench把需求分成 code2test、comment2context、trace2code、edit2ripple 和 selective retrieval；没有单一 retrieval family 在所有任务占优，记录到的 Agent 轨迹在 27%–35% 样本中完全漏掉 gold file；
• 这两者共同说明 retrieval 不是模型请求前的一次静态预处理，而是与假设、工具反馈和任务阶段共同演化的策略。

更完整的 acquisition metric 应包含：

coverage       找到了多少必要证据
precision      引入多少无关证据
rank           高价值证据出现得多早
budget yield   每 1K token / 100 lines 提供多少有效信息
abstention     没有可靠证据时能否停止或换策略
provenance     能否解释证据来源与版本
downstream lift 对最终定位/修复的真实提升

Filesystem 作为外部认知空间

Coding Agents are Effective Long-Context Processors展示了一个重要方向：超长信息不一定要进入 latent attention；Agent 可以用 filesystem、搜索和可执行代码把信息外化、分块、索引和再读取。

这不是简单的“把 context 写文件”。其结构意义是把认知负担拆成：

• 模型负责形成查询、假设和选择策略；
• workspace 负责保存可寻址的外部状态；
• tools 负责确定性过滤、聚合和计算；
• context engine 只把下一决策所需证据带回模型。

因此长上下文系统存在两条互补路径：latent long context 与 explicit external cognition。前者适合跨片段整体整合，后者适合大规模、可索引、可计算和可审计的信息。

5.5 Compaction

Compaction 的目标不是写摘要，而是构造可恢复任务状态。必须保留：

• goal 与硬约束；
• 用户决定；
• 已确认事实及 provenance；
• 失败尝试和失败原因；
• 已发生的 effect；
• 当前 diff/artifact 指针；
• 未验证项；
• 下一步最高信息增益动作。

Compaction 有三种不同实现层：

CompactionRL将任务执行与 summary generation 联合做强化学习，并在 coding/terminal benchmarks 上报告提升。它代表一个新判断：compaction 不再只是 token 超限后的工程 fallback，也开始成为模型的原生长期行动能力。

Anthropic 的长任务实验则区分了 compaction 与 context reset：前者在同一会话内摘要历史，后者以结构化 handoff 启动全新上下文，可消除“context anxiety”和累积污染，但要求外部 task state 更可靠。参考：Harness design for long-running applications。

5.6 Memory Transition：写记忆本身也是高风险状态变化

Memory 不能只评 retrieval accuracy，还必须评每次 write / revise / merge / delete 是否保持事实完整性。把旧 memory 状态记为 M_t，新观察为 E_t，更新为 M_{t+1}，至少检查：

• Coverage：重要新信息是否被保留；
• Preservation：无关旧事实是否被错误覆盖；
• Faithfulness：新增 claim 是否由 evidence 支持；
• Temporal correctness：旧事实是失效、被否定还是仍在另一时间范围有效；
• Provenance continuity：merge 后是否仍能追到原始来源；
• Scope isolation：一次 task/user/project 的信息是否泄漏到另一 scope。

TrustMem把 coverage、preservation、faithfulness 放入 Memory Transition Verifier，并把 omission、corruption、hallucination 定义成转移级失败。这比只检查最终回答更接近持久 Agent 的真实风险：一次错误更新会成为未来所有 session 的系统状态故障。

5.7 Typed Memory 与 Provenance-role Separation

扁平自然语言 memory 会把“谁说的、在什么时间、是证据还是推断”压成同一文本。更可靠的中间表示应至少区分：

EvidenceAtom   原始可引用证据
ClaimAtom      对证据的可验证主张
CueAtom        用于未来 retrieval 的线索
PolicyAtom     经验证的程序性策略
PreferenceAtom 用户明确表达的偏好

MemIR把 source monitoring 变成结构约束，只允许被 evidence 支持的 claim 获得 factual authority。这对应一个普遍原则：provenance 不应只是 metadata，而应参与 authorization 和生成。

5.8 Memory Contagion：错误 evaluator 会跨时间传播

Memory 的风险不只来自摘要错误。若负责评价 trajectory 的 judge 有长度偏好、权威偏好或其他系统性偏差，这种偏差会被蒸馏进 memory，再影响未来 Agent，即使 consolidation 本身完全正确。Memory Contagion把这一现象定义为跨时间的 evaluator bias propagation。

因此 memory learning loop 必须同时治理：

• experience 是否代表真实任务分布；
• evaluator 是否经过校准；
• consolidation 是否保持证据；
• retrieval 是否放大某类偏差；
• memory 是否支持版本、回滚、隔离与 unlearning；
• 新模型是否仍适合旧策略。

典型失败

• transcript、context、journal、memory 共用一个 messages 数组；
• 1M context 被误当检索替代品；
• compaction 丢掉负面证据，Agent 重复失败；
• 模型猜测直接写入长期 memory；
• repo 更新后旧 memory 无失效机制；
• tool schema 过多挤占高价值证据。

2026 前沿判断

Context research 正从笼统的“给模型更多信息”拆成 acquisition、selection、compaction、external cognition 和 memory transition 五个可独立评测的问题。Memory 正从“保存更多历史”走向“蒸馏有 provenance 的可迁移策略”，同时必须防范 corruption、role collapse 和 evaluator bias 的跨时间传播；长 context 让 compaction 触发更晚，但不会消除注意力、成本、缓存和污染问题。

6. 第三层：Tools 与 Environment

深度卷：Tool Execution 与 Environment。

6.1 Tool 不是函数，而是 effect contract

Discovery
  -> Schema Validation
  -> Normalization
  -> Preflight
  -> Policy / Permission
  -> Scheduling
  -> Execution
  -> Receipt / Artifact
  -> Observation

Tool contract 至少需要描述：输入 schema、capability、read/write effect、幂等性、取消语义、timeout、输出界限、错误类型和证据。

6.2 Effect Taxonomy

只按工具名授权是不够的；同一个 shell 可以是只读查询，也可以是不可逆发布。

6.3 Coding Agent 的关键工具域

• File/Edit：content hash、minimal patch、冲突、encoding、symlink；
• Search：lexical、symbol、AST、graph、semantic；
• Shell/PTY：stream、stdin、signal、process tree、backpressure；
• Git：worktree/index、用户未提交修改、merge、commit；
• Build/Test：环境、flakiness、timeout、artifact、verifier；
• LSP/IDE：selection、diagnostic、reference、diff；
• Browser/Computer Use：视觉状态、非确定性 UI、副作用；
• Remote/Sandbox：snapshot、identity、network、resource lifecycle；
• MCP/Plugin：外部能力发现、信任和版本。

6.4 并发调度

并行不是根据模型一次返回几个 call 决定，而是根据 effect 是否冲突：

• read/read 通常可并发；
• 同一资源 read/write 或 write/write 冲突；
• 文件路径存在目录/alias/symlink 关系；
• Git index、端口、进程表和数据库可能是隐含全局资源；
• 并发失败必须保留每个调用独立的 effect 和 receipt。

典型失败

• shell 被抽象成 exec(string)；
• timeout 被误解为“没有副作用”；
• output 截断却未告知模型；
• 同一文件并行编辑覆盖用户修改；
• 自动 retry 非幂等外部调用；
• tool error 只返回自然语言，无法分类；
• 大输出直接污染 context。

7. 第四层：Runtime 与 Distributed Systems

深度卷：Durable Agent Runtime 与分布式系统。

这一层负责让长任务在真实机器和服务上可靠存活。

核心问题

• 谁拥有 session/turn 的推进权？
• 状态怎样持久化、恢复和迁移？
• 工具副作用发生在崩溃边界时怎么办？
• 如何控制资源、并发、队列和成本？

7.1 Lifecycle Scopes

典型作用域：

App -> Workspace -> Session -> Agent -> Turn -> Step -> Tool Call

每层都应明确：identity、config、resource、persistence、sharing、destroy 和 observability。全局单例很容易导致配置泄漏和生命周期混乱。

7.2 Persistence

• append-only journal；
• schema version 与 migration；
• reducer/projector；
• snapshot + replay；
• 大 artifact/blob 外置；
• 尾部半写、corruption、atomic repair；
• single writer、lease 或分布式一致性策略。

7.3 Effect Reconciliation

最危险窗口：tool intent 已持久化、外部 effect 已发生、receipt 尚未持久化，进程崩溃。

正确做法依赖 effect：

• 查询 operation ID；
• 使用 idempotency key；
• 对比外部状态；
• 记录 unknown，而不是假设成功/失败；
• 无法确认时升级人工处理。

7.4 Resource System

• per-user/project/session quota；
• model/tool/sandbox/artifact 各自 backpressure；
• retry storm 与 circuit breaker；
• sleep/resume、idle teardown、prewarm；
• remote workspace snapshot；
• cancellation 与 cleanup；
• worker crash、lease expiry、recovery storm。

7.5 Brain / Hands / Evidence 的解耦

长任务 runtime 正形成三个相对稳定的边界：

Brain     model + harness policy + context strategy
Hands     workspace + tools + sandbox + credentials
Evidence  journal + artifacts + trace + verifier

“Brain”会随着模型和 prompt 快速变化；“Hands”必须提供稳定、可取消、可审计的 effect contract；“Evidence”必须跨模型和 worker 生命周期保持可恢复性。

Anthropic 的 Managed Agents 架构强调把 recoverable session context storage 与 harness 自由的 context management 分开，原因是未来模型需要何种 context 策略无法提前固定。这个判断可以推广为：持久化系统保存可恢复事实，不替 policy 决定下一次模型究竟看什么。

7.6 Execution Alignment

Harness-Bench提出的高频失败并不一定是模型“想错了”，而是 plausible reasoning 与 tool feedback、workspace state、evidence 或 output contract 脱节。可以把 execution alignment 分成四个同步问题：

• decision-state alignment：模型依据的状态是否仍然新鲜；
• intent-effect alignment：tool 实际 effect 是否符合模型意图；
• effect-observation alignment：返回给模型的 observation 是否真实完整；
• outcome-contract alignment：最终 artifact 是否满足外部验收，而不是语言上看似合理。

这四个边界比“模型是否 hallucinate”更容易被工程化定位，也更接近 Agent Infra 的直接责任。

典型失败

• UI connection 断开导致任务状态丢失；
• process memory 是唯一事实源；
• 所有重试共用同一 budget 之外的隐式次数；
• crash 后盲目 replay tools；
• background completion 随意插进模型 context；
• provider/sandbox 同时恢复引发惊群。

8. 横切控制面：Loop、Planning、Policy、Verification

深度卷：Agent Loop、Planning、Policy 与 Verification。

8.1 Loop

Loop 的正确抽象是显式状态机，而不是 while(true)：

admit
  -> materialize context
  -> infer
  -> validate decision
  -> authorize
  -> execute/schedule
  -> persist observations
  -> verify
  -> continue / replan / complete / fail / cancel

8.2 Error Semantics

Retry、recover、replan、fallback 和 failover 是不同概念。把它们都写成重试会隐藏责任边界。

8.3 Planning

Plan 适合长 horizon、跨模块、高风险、需要用户决定或可并行任务。短、低风险、反馈即时的任务中显式 plan 可能只是额外 token 和过期状态。

Plan 应记录：目标、约束、未知项、任务依赖、acceptance criteria、状态和证据；它是可修正的任务模型，不是强制执行脚本。

8.4 Verification

验证优先级：

1. deterministic test/build/type/schema；
2. diff/policy/invariant checks；
3. runtime/browser/visual evidence；
4. domain-specific oracle；
5. 校准过的 LLM judge；
6. human review。

Verifier 也可能错误、flaky 或覆盖不足，因此必须成为可审计对象，而不是神谕。

8.5 Budgets

至少考虑 step、wall time、token、cost、tool attempts、permission burden 和 external effect budget。Budget 是产品和可靠性 contract，不只是防止死循环。

9. 第五层：Protocols 与 Extension Ecosystem

深度卷：Protocols、Identity 与 Observability。

9.1 MCP

MCP 解决能力、工具和资源如何被 host 发现与调用；不解决 Agent 的 planning、state、permission、verification。

知识点：

• transport 与 discovery；
• capability/schema negotiation；
• auth 与 delegated identity；
• cancellation、timeout、liveness；
• tool/resource trust；
• versioning 与 schema cache；
• effect idempotency；
• server output prompt injection；
• degraded/unavailable server 的隔离。

2026-07-28 稳定规范的结构性变化

官方仓库已在 2026-07-28 将这一 revision 标记为 stable release。稳定规范不等于生态已经同步完成迁移：SDK、client 与 server 会按各自节奏采用，生产系统仍必须显式协商版本，并兼容既有 sessionful lifecycle。

最新规范不是一次字段升级，而是从 connection/session-oriented protocol 转向 request-oriented protocol：

• 移除 protocol-level session 与 Mcp-Session-Id；跨调用业务状态改用 server-minted handle 作为普通参数；
• 移除 initialize / initialized，每个请求在 _meta 携带 protocol version 与 client capabilities；
• 新增 server/discover 做版本、能力与身份发现；
• 用 subscriptions/listen 统一 server-to-client change notification；
• 移除 ping、协议日志级别状态和 SSE resumability；断流请求要以新 request ID 重发；
• 用 Multi Round-Trip Requests 的 input_required / inputResponses 代替 server 主动反向请求；
• 所有 result 显式携带 resultType；
• list/read 结果增加 ttlMs 与 cacheScope，工具列表要求 deterministic ordering；
• 标准化 OpenTelemetry traceparent / tracestate / baggage 传播；
• Roots、Sampling、Logging 被标记 deprecated，模型调用与日志逐步回归 host/OTel 的明确责任。

参考：MCP 2026-07-28 Key Changes。

对 Host 架构的影响

旧思路：connection ≈ session ≈ capability snapshot ≈ liveness
新思路：request metadata + discover + explicit state handle + cache policy

因此 host 必须重新明确：

• transport connection 不能代表业务 state；
• retry request 与重放 effect 是两件事；
• tool list cache 需要 version/hash/TTL/scope；
• in-flight response stream 丢失后要判断 tool 是否幂等；
• MRTR 的 requestState 属于 server workflow，不应污染 Agent session state；
• 新旧 SDK 兼容必须封在 protocol adapter，而不是扩散到 tool plane。

9.2 A2A

A2A 解决独立、可能不透明的 Agent 系统如何发现彼此能力、协作处理长任务并交换 message/artifact。当前稳定规范为 1.0 系列，官方 1.0.1 于 2026-05 发布。

核心对象：

• Agent Card：身份、能力、skills、protocol bindings、auth；
• Message：一次交互输入或输出；
• Task：可持续、可查询、可取消的协作状态；
• Artifact：Agent 生成的结构化交付物；
• Context ID：关联一组相关交互；
• Push/Stream：异步进展和状态更新。

A2A 1.0 把 application protocol 与 JSON-RPC、gRPC、HTTP+JSON bindings 分离，并要求不同 binding 保持功能、错误和认证语义一致。参考：A2A 1.0 Specification、A2A Releases。

协议互操作没有解决 trust composition：Agent Card 声称有某能力，不等于调用方应授权；远程 Agent 返回 artifact，也不等于 artifact 已验证。身份、delegation chain、least privilege、non-repudiation 和 effect receipt 仍需独立治理。

9.3 ACP

ACP 聚焦 IDE/client 与 coding agent 的互操作：session、prompt、tool/progress、permission、terminal、文件与 diff 展示。关键问题不是消息格式，而是 client presentation state 与 agent runtime state 的所有权。

截至 2026-08-03，ACP 官方仓库把 wire protocol 1 标为当前稳定版本；schema/crate 的 1.x 发布号是 artifact version，不等于 wire protocol version，正在开发的 protocol v2 仍通过 unstable_protocol_v2 feature 暴露。实现必须在 initialize 阶段协商 protocolVersion，不能由包版本猜 wire compatibility。参考：ACP repository、ACP releases。

9.4 LSP

LSP 不是 Agent protocol，而是代码语义基础设施。它提供 symbol、reference、diagnostic、rename 等精确结构信号，可与 lexical/AST/graph/semantic retrieval 组合。

9.5 OpenTelemetry GenAI Semantic Conventions

Agent observability 正从各家自定义 trace 走向公共语义层。OpenTelemetry 2026 年的 GenAI conventions 已覆盖：

• inference client spans；
• invoke_agent 的 client/internal spans；
• execute_tool spans；
• retrieval spans；
• evaluation events；
• reasoning tokens、cache read/create tokens；
• streaming TTFC 与 per-output-chunk timing；
• agent version、tool definitions 和 tool call details。

这里的“覆盖”只表示规范已经定义相应语义，不表示全部稳定。截至 2026-08-03，独立 GenAI semantic-conventions 仓库中的 agent spans 及多数 gen_ai.* 字段仍标为 Development；生产实现应锁定具体版本并保留 vendor/domain events，不能把跨版本字段稳定性当作既成事实。

参考：OpenTelemetry Semantic Conventions releases、GenAI conventions repository。

标准化的价值是跨 provider/harness 比较和 trace propagation；局限是语义规范仍在快速演进，而且默认捕获 prompt、tool arguments/results 会带来源码、secret、高基数和成本风险。正确做法是：通用 span 语义 + 产品自己的 domain events + 默认内容关闭 + 明确采样/脱敏策略。

9.6 Skills、Hooks、Plugins

• Skill：可发现的程序性知识或工作流；
• Hook：生命周期上的确定性代码执行；
• Plugin：打包分发 capability/config/skill/tool；
• Agent profile：模型、prompt、tool allowlist 等策略组合。

必须处理 scope、precedence、version、trust、更新、隔离和 provenance。来自 repository 的配置在 trust 之前不能自动获得高 authority。

9.7 四种协议不要混

它们可以组合，但共享 transport 或 JSON 并不意味着状态、身份、取消和错误语义天然一致。

9.8 Identity 与 Delegation 正成为独立控制面

随着 MCP 和 A2A 把能力暴露给远程 Agent，传统“用户 token 直接交给 Agent”会产生 confused deputy 与过度授权。需要分别回答：

• 这个 Agent 实例是谁、由谁创建、运行哪个版本；
• 它代表哪个 user/workload，在什么时间范围内行动；
• authority 是直接授予还是从上游 Agent 委派；
• 每次 action 的 audience、resource、scope 与 policy；
• delegation 是否可衰减、撤销和审计；
• receipt 能否支持 non-repudiation。

NIST 2026 年启动 AI Agent Standards Initiative，并把 agent identity、authorization 和 interoperable protocols 列为核心研究方向。参考：NIST AI Agent Standards Initiative、Agent Identity and Authorization concept。

10. 第六层：Coordination 与 Multi-agent

深度卷：Multi-agent Coordination。

10.1 为什么需要多个 Agent

合理动机：

• 并行独立调查；
• context 隔离；
• 专业工具/权限隔离；
• planner、executor、evaluator 的角色分离；
• 大任务的 ownership 划分。

错误动机：

• 认为 agent 数量天然增加智能；
• 用协调掩盖单 Agent loop 不可靠；
• 没有独立 verifier 仍盲信投票；
• 为了架构新颖引入角色扮演。

10.2 Topology

10.3 Task Decomposition Vector

是否值得 multi-agent 取决于：

• 可并行度；
• 输入是否可打包；
• 输出是否可独立验证；
• shared mutable state 强度；
• 错误相关性；
• handoff token 与合并成本；
• 工具/环境竞争；
• 主 Agent 是否能拒收产物。

10.4 Coordination Contract

目标、范围、已知事实、输入 artifact、允许 effect、禁止项、deadline/budget、输出 schema、验收器和 ownership 必须明确。否则 multi-agent 只是把上下文混乱分布到多个地方。

10.5 Agent 数量不是正确的 Scaling Unit

更准确的资源单位是：

useful independent exploration
  / (handoff + coordination + merge + verification cost)

Towards a Science of Scaling Agent Systems最新 v3 在 260 种 configuration、六类 agentic benchmark、五种 architecture 与三个 model family 上总结出以下可量化效应：

• 在固定 compute 下，tool-heavy task 更容易被 multi-agent coordination overhead 拖累；
• 当 single-agent baseline 已超过约 45% 时，协调收益出现明显饱和或转负；
• independent agents 的 unchecked error amplification 为 17.2×，centralized coordination 可把它压到 4.4×；
• 基于任务属性的预测框架对 held-out configuration 的最优 coordination strategy 预测达到 87%。

这些数字不能直接外推到所有产品，但揭示了正确因变量：任务可并行度、工具密度、single-agent capability、error correlation 和 coordination topology，而不是“用了几个 Agent”。

10.6 Coordination 的四类成本

因此 multi-agent 的核心工程问题逐渐从“角色怎么写 prompt”转向 task contract、state isolation、delegated identity、artifact provenance 和 centralized verification。

2026 前沿判断

最新研究更支持“conditional scaling”：可并行任务可能显著受益，严格顺序或 tool-heavy 任务可能明显退化；集中协调通常比独立 Agent 更能控制错误放大。产业侧的变化是 A2A 把跨供应商 Agent 协作标准化，但协议互通只解决 communication，不解决 decomposition quality、trust composition 与 artifact verification。Multi-agent 是调度和组织选择，不是产品成熟度标志。

11. 第七层：Evaluation、Data 与 Learning Loop

深度卷：Evaluation、Trace、Data 与 Learning。

11.1 Eval 评的是什么

System under evaluation
  = model
  + prompt/context
  + tools
  + runtime/harness
  + environment
  + budget
  + verifier

缺少任何一项，分数都难以复现和归因。

11.2 Eval 类型

11.3 Task Validity

一个评测任务必须检查：

• prompt 是否给出必要需求；
• repository commit 与依赖是否可复现；
• tests/oracle 是否正确、充分且不过度约束；
• 是否存在投机捷径；
• 是否被训练污染；
• 是否代表目标用户分布；
• scorer 是否支持评测想声称的结论。

11.4 Metrics Tree

主指标：verified、regression-free、被用户接受的任务完成。

辅助指标：

• first-pass / eventual success；
• time/token/cost；
• steps/tools 与重复工作；
• permission prompts 与人工接管；
• recovery rate；
• destructive incident；
• irrelevant diff；
• failure taxonomy；
• 用户后续修正与回滚。

11.5 Outcome 与 Trajectory

Outcome 告诉我们是否成功；trajectory 告诉我们为什么。最后失败的测试通常不是第一次错误决定。高质量归因需要反向因果链和 counterfactual replay。

11.6 Data Flywheel

real task trace
  -> privacy filtering
  -> failure clustering
  -> reproducible task
  -> human audit
  -> model/harness ablation
  -> regression set / training data
  -> staged rollout

“收集更多 trace”不是闭环。没有隐私、task validity、归因和回归治理，数据只会扩大噪声。

11.7 Evaluation Cube

单一 leaderboard 无法覆盖 Agent 系统。更完整的评测空间至少有四个轴：

Capability stage：understand -> retrieve -> plan -> act -> recover -> verify
Task horizon：single-step -> issue -> feature -> version/roadmap -> continuous work
System config：model × harness × tools × effort × budget × environment
Risk level：read-only -> reversible write -> external consequential effect

任何新 benchmark 都只覆盖这个 cube 的一部分。评价它时要说明覆盖面，而不是把一个 resolved rate 当成“Agent 能力”。

11.8 2026 Coding-Agent Benchmark 版图

这些 benchmark 的共同方向是把端到端“是否过测试”拆成 retrieval、reasoning、harness、long horizon、cost 和 trajectory。

11.9 当前最重要的量化证据

• DeepSWE 任务是原创且不回流上游，hand-written verifier 与独立 judge 的 disagreement 为 1.4%，而论文对 SWE-Bench Pro inherited tests 的重审 disagreement 为 32.4%；其 reference solution 涉及的代码量约为 SWE-Bench Pro 的 5.5×；
• RoadmapBench 的最强被测系统也只完成 39.1%，说明单 issue 高分不能外推到多目标长期开发；
• Harness-Bench 在 5,194 条轨迹中观察到 completion、process quality、efficiency 和 failure behavior 随 model-harness pairing 大幅变化；
• Claw-SWE-Bench 中同一 GLM 5.1 backbone，minimal adapter 与 full adapter 的 Pass@1 从 19.1% 变为 73.4%；跨 sweep 中 model choice 影响 29.4 个百分点，harness choice 影响 27.4 个百分点；
• OpenAI 对 SWE-Bench Pro 的审计认为约 30% 任务存在破坏性问题并撤回推荐，说明“测试可运行”不等于“评测有效”。

这些结果不应被用来宣布某个 benchmark 永久优越；它们支持的是更稳健的方法论：原创任务、手写或审计过的 verifier、完整 trajectory、model-harness 联合报告和分组件诊断。

11.10 Agent Eval Card

任何可信结果至少披露：

claim: 这个评测支持什么结论
task_set:
  source: original / mined / private / live
  validity_audit: solvability, oracle, leakage, contamination
system:
  model: exact version
  harness: exact version + config
  tools: schemas + environment
  context: retrieval / compaction / memory policy
  effort: reasoning and sampling
budget: turn, token, time, cost, retries
execution: hardware, sandbox, network, dependency snapshot
scoring: verifier version + judge calibration
runs: N, variance, confidence interval
failures: taxonomy + exclusions + refusals + fallbacks
artifacts: trajectories, diffs, logs, reports

没有这张卡，排行榜更像产品展示，而不是可复现科学结论。

2026 前沿判断

Coding eval 正从“一个端到端 pass rate”分化为 component diagnosis、long-horizon validity、harness science、trajectory attribution 和 online trust metrics。Benchmark contamination、broken tasks、harness 不透明和 budget 不一致足以改变结论；评测工程已成为 Agent 研发核心，而不是发布前打分环节。

12. 第八层：Safety、Trust 与 Governance

深度卷：Security、Trust 与 Governance。

12.1 Authority 与 Trust

必须区分：

• system/developer policy；
• 用户直接意图；
• repository/config/hook；
• webpage/MCP/tool output；
• model 生成的建议。

外部内容是数据，不因为被模型读取就获得指令 authority。

12.2 四类确定性边界

• Filesystem：workspace、mount、symlink、path；
• Process：用户、syscall、resource、child tree；
• Network：egress、domain/IP、DNS、SSRF；
• Identity/Secret：credential scope、broker、审计和 lifetime。

Prompt policy 是概率约束，不能替代这些边界。

12.3 Permission

权限应按 capability + effect + target + context 判断，而不是工具名。Prompt 应说明具体风险；低风险动作应由 sandbox 自动收敛，高风险、跨边界或不可逆动作才升级人类决定。

12.4 Threats

• prompt injection；
• confused deputy；
• malicious repository config/hook；
• tool/MCP output injection；
• symlink/path escape；
• SSRF/DNS rebinding；
• secret exfiltration；
• dependency/plugin supply chain；
• trace/artifact 泄漏；
• approval fatigue；
• autonomy 失控与延迟发现。

OWASP Agentic Top 10（2026）

OWASP 将 Agent 风险从 prompt injection 扩展为完整行动链：

参考：OWASP Top 10 for Agentic Applications 2026。这份列表适合做 threat discovery，不替代针对具体 architecture 的 data-flow、authority 和 effect threat model。

12.5 Influence Provenance：从数据来源追到行动

传统 data provenance 只回答信息从哪里来；Agent 安全还需要回答它如何影响了决策：

untrusted source
  -> retrieved observation
  -> derived claim
  -> plan/decision
  -> requested capability
  -> external effect

每条边需要 authority、scope 和 justification。高风险 action 若只能追溯到 untrusted observation，而不能追溯到用户 intent 或可信 policy，就应被拒绝或升级。

ARGUS / AgentLure用 influence provenance graph 审计不可信 context 如何传播到决策，并报告在其 benchmark 上把 attack success rate 降到 3.8%、保留 87.5% task utility。该数字只对论文设置有效，但“source-to-decision influence”是比关键词 injection detector 更结构化的方向。

12.6 Prompt Annotation 与 Channel Closure

AgentSecBench给出一个关键安全区分：

• delimiter、标签和“不要听外部指令”是在模型可见通道中的 annotation；
• provenance projection、capability restriction、tenant filtering 和 output validation 才可能关闭 unauthorized channel。

因此安全评测应同时测：

• adversarial success；
• benign task utility；
• latency/cost；
• 是否真正移除了模型可见的非法数据/capability；
• 防御是否只是过度拒绝。

AgentDyn在 60 个开放任务、560 个 injection case 上发现，许多防御要么仍不安全，要么显著 over-defense。安全性不能用 attack success 单指标换取完全不可用的 Agent。

12.7 Governance

• data retention 与删除；
• tool/plugin provenance；
• policy version 与审计；
• action receipt；
• incident replay；
• enterprise boundary；
• human override；
• 模型/策略更新后的重新评测。

2026 年 NIST 对 Agent security RFI 的总结认为，传统 cybersecurity 原则仍然有效，但必须适配 Agent 的模型—软件组合风险；社区普遍把安全问题视为 adoption barrier，并要求实现指南、信息共享与标准。参考：NIST AI 800-5。

治理不应停在 policy 文档。最低闭环是：identity → delegated authority → action policy → effect receipt → trace → incident replay → policy/eval update。

2026 前沿判断

Agent 安全的主控制面正从“让模型自我约束”转向“provenance-aware information flow + capability containment + delegated identity + 少而清晰的 consequential approval”。Prompt 防御仍有价值，但不能充当唯一强制边界；安全也必须联合评估 benign utility，避免以完全拒绝换取虚假安全。

13. 第九层：Human-Agent Interaction

深度卷：Human-Agent Interaction 与 Autonomy。

13.1 人机关系不是全自动/手动二元选择

同一产品可根据 effect risk、用户熟练度和 verifier 强度动态选择模式。

13.2 Autonomy 不是一个全局开关

更合理的 autonomy state 是一个向量：

scope        能访问哪些 workspace/data
capability   能调用哪些 tools
effect       能造成哪级副作用
horizon      能连续运行多久/多少 steps
budget       能消耗多少 token/cost/compute
oversight    哪些阶段需要人介入
verification 什么证据才能自动继续或完成

同一 Agent 可以在 repo 内搜索上高度自治，在写文件上 bounded autonomy，在部署/外部消息上必须确认。静态的 auto/yolo 只是一种粗粒度产品映射。

Anthropic 对数百万真实交互的分析发现，Claude Code 最长一组 session 中，无人工介入时长在三个月内从不足 25 分钟上升到超过 45 分钟；这说明 autonomy horizon 正快速增长，但该指标不等同于正确率或安全性。参考：Measuring AI agent autonomy in practice。

13.3 Oversight 是四种工作，不只是最终 Review

2026 年对有经验开发者的访谈研究将真实 oversight 分为：

• a priori control：事前限定 scope、工具、规则与风险；
• co-planning：共同澄清目标、分解和决策点；
• real-time monitoring：观察 progress、异常和方向漂移；
• post hoc review：检查 diff、测试、artifact 和副作用。

参考：Human oversight of agentic systems in practice。这意味着“human-in-the-loop”并不是单个 approval API，而是一组跨任务生命周期的认知和控制工作。

13.4 Dynamic Autonomy 与 Earned Trust

Hedwig提出根据跨 session 的 developer-agent interaction 动态调整 Coding Agent autonomy。这个方向的核心并不是学习“用户总是点允许”，而是将信任绑定到具体条件：

• 熟悉的 repo/task/tool/effect；
• 过去 verifier 与 review 结果；
• 当前行动是否越出历史分布；
• 失败后是否自动降低 autonomy；
• 用户是否能查看、修改和删除学到的规则。

否则 learned autonomy 很容易把 approval fatigue 误学成永久授权。

13.5 关键交互语义

• 用户消息是 interrupt、append 还是 replace；
• plan 是审批对象还是透明状态；
• progress 展示事实还是模型叙述；
• permission 是否解释具体 effect；
• diff/测试/未验证项怎样呈现；
• background task 完成如何进入当前任务；
• failure 是否可恢复、可理解、可接管；
• resume 后用户能否知道系统真实状态。

13.6 Trust Calibration

Agent 既不能用流畅语言伪装确定性，也不应对每个普通动作发出警告。信任来自：

• 行动边界可预测；
• progress 与真实状态一致；
• 失败和未知项不隐藏；
• 关键 effect 可审计；
• 验证证据易于检查；
• 用户能在正确粒度接管。

典型失败

• “命令已启动”被展示成“任务完成”；
• plan 过长但不包含决策点；
• approval 文案没有 target/effect；
• resume 后重复已经完成的工作；
• 用户纠正没有进入 durable task state；
• UI transcript 与 runtime state 不一致。

14. 第十层：Economics 与 Product Strategy

深度卷：Agent Economics 与 Product Strategy。

14.1 Agent 的真实成本函数

Total Cost
  = model tokens
  + tool/runtime compute
  + latency and waiting
  + human supervision
  + correction/rework
  + failure and trust loss

便宜模型不一定更省；昂贵模型如果显著减少步骤、接管和错误，整体成本可能更低。

14.2 能力路由

路由维度包括：

• task complexity/horizon；
• context size 与 modality；
• tool density；
• latency sensitivity；
• effect risk；
• verifier strength；
• user plan/quota；
• provider availability；
• data boundary。

模型路由不能只按 token 单价，也不能在不兼容 preserved reasoning/tool protocol 的情况下随意切换。

14.3 产品优先级

好的优先级来自 failure cohort：频率 × 用户损失 × 可修复性 × 战略价值。不要从功能清单开始。

每个能力都应回答：

• 解决什么真实失败；
• 责任在 model 还是 harness；
• success metric 和 guardrail；
• 增加多少长期复杂度；
• 模型变强后是否应删除；
• 是否改变用户信任边界。

14.4 护城河

Agent 产品的长期差异不只来自模型：

• 高质量真实任务与评测资产；
• 深工具和环境集成；
• 可恢复 runtime；
• context/state/memory 质量；
• 安全与企业边界；
• 用户 workflow 和反馈闭环；
• 模型—harness 联合迭代速度。

14.5 工作单位从 Message 转向 Delegated Task

Agent 产品的使用单位正在从“人发一条消息、模型回一条答案”变成“人建立任务 contract、Agent 消耗一段机器时间交付 artifact”。这改变了产品和经济学：

• 用户同时管理的是 task portfolio，而不是聊天窗口；
• 关键瓶颈从输入速度变成 specification、review 和 exception handling；
• wall-clock 可通过并行 Agent 压缩，但总 compute 与监督负担可能上升；
• throughput 应按 verified artifacts/任务衡量，而不是消息数和 token 数；
• 高阶用户的稀缺能力是选择委派边界、提供 context 和快速验收。

OpenAI 2026 年内部/产品使用研究报告称，样本用户越来越多地提交估算超过一小时的人类工作任务，重度用户一天可并行产生远超 24 小时的 Agent turn time。这是单一产品生态的数据，不能直接代表整个市场，但它清晰显示：**Agent parallelism 把人的工作从执行队列转成决策与验收队列。**参考：How agents are transforming work。

14.6 新瓶颈：Verification Capacity

当 Agent 生成速度超过人的 review 能力，组织不会线性获得产出，而会积累未验证代码、自动化与决策债务。可扩展的方向包括：

• 更强 deterministic verifier；
• risk-based review routing；
• independent agent review，但保留 correlated-error 防线；
• artifact provenance 与 change ownership；
• 让 Agent 产出更小、更可验证的 change；
• 将 human attention 留给 spec、architecture、exceptions 与 consequential effects。

因此未来 Agent 组织的极限可能首先由 verification bandwidth 决定，而不是 generation bandwidth。

15. 十组不可混淆的核心张力

深度卷：跨层张力、失败归因与前沿判断。

15.1 Model vs Harness

模型决定概率策略上限；harness 决定可见证据、行动空间、状态、反馈和边界。没有固定一侧的 ablation，不能归因。

15.2 Long Context vs Context Engineering

长窗口解决容量，context engineering 解决相关性、authority、顺序、成本、缓存和污染。前者增强后者，不替代后者。

15.3 Reactive Loop vs Planning

即时反馈强、任务短时 reactive 更轻；horizon 长、依赖复杂、风险高时 plan 提供控制价值。计划不是越详细越好。

15.4 Single Agent vs Multi-agent

单 Agent 避免 handoff 与共享状态成本；multi-agent 利用并行和隔离。选择取决于任务结构，不取决于“先进程度”。

15.5 Generic Abstraction vs Model Specialization

统一 contract 降低系统复杂度；过度统一会抹掉 thinking、tool、media、effort 的模型优势。正确方向是稳定语义 + capability-aware adapter。

15.6 Autonomy vs Control

更少人为干预可提高吞吐；风险取决于 effect、可逆性和 verifier。更高 autonomy 必须由更强 containment、观测和恢复支持。

15.7 Outcome vs Process

只看 outcome 容易奖励投机和危险路径；只看 trajectory 容易过度约束模型。确定性结果 + 关键过程 guardrail + 成本/信任指标需要共同存在。

15.8 Memory Utility vs Memory Integrity

保存和检索更多经验可能提升短期成功率，也可能把 hallucination、过时事实和 evaluator bias 固化为长期系统状态。Memory 系统必须把 transition verification、provenance、scope、rollback 与 utility 一起优化。

15.9 Interoperability vs Trust Composition

MCP/A2A 降低能力连接成本，但也让身份、authority、schema、artifact 和故障跨供应商传播。能通信不等于能信任；协议 adoption 必须配套 delegated identity、capability policy、provenance 和 verifier。

15.10 Generation Throughput vs Verification Capacity

并行 Agent 可快速扩大生成产能，却可能把瓶颈推到 specification、review、integration 和 incident response。真正可扩展的系统优化 verified outcome throughput，不优化未验收 artifact 数量。

16. 统一 Failure Taxonomy

深度卷：跨层张力、失败归因与前沿判断。

16.1 按首次责任边界分类

16.2 按行为表象分类

• hallucination；
• premature completion；
• loop/repetition；
• context drift；
• over-edit / irrelevant change；
• under-exploration；
• destructive action；
• silent fallback；
• retry storm；
• stale memory；
• subagent conflict；
• verifier gaming。

表象不能直接等于根因。“hallucination”可能来自缺 context、工具失败未暴露、旧 memory 或真正的模型推理错误。

16.3 First Bad Decision

归因方法：

1. 从最终失败反向建立证据链；
2. 找到第一个当时已有足够信息、却选择了错误行动的 step；
3. 区分此前隐藏的系统缺陷与该 step 的可行动错误；
4. 替换该决定做 counterfactual replay；
5. 如果后续恢复，才提高根因置信度；
6. 将 failure 变成可复现 eval，而不只是事后故事。

17. 判断任何新 Agent 技术的统一框架

深度卷：跨层张力、失败归因与前沿判断。

17.1 先分开两条轴

provenance / inspectability  ── 这项事实能被怎样核对？
frontier capability         ── 它把真实可完成任务推进了多少？

两条轴不能互相替代。公开实现中的 feature 可能从未成为稳定产品路径；官方产品已经支持的能力可能依赖未公开服务；一次 hands-on 成功不能代表平均可靠性；受控 benchmark 也未必覆盖真实 workflow。统一使用四类事实面：

PUB 不是最高等级，PRODUCT 也不是效果证明。真正的 frontier 判断至少比较：task envelope、autonomy horizon、durable state/recovery、steering 与 parallel orchestration、tool/world reach、verification、security boundary、latency/cost，以及实际使用中产生的 verified work。

17.2 十二问

遇到新模型、框架、memory 方法、multi-agent 论文、协议或产品时，按以下十二问分析：

1. 当前 claim 属于 PUB / PRODUCT / TRACE / EVAL 哪个事实面，哪些仍是 inference / unknown？
2. 它先进在 capability 的哪个维度，而不是只先进在版本日期或代码可见性？
3. 它解决的是哪个时间尺度、哪个层的什么失败？
4. 它改变了 model、harness、environment 还是 verifier？
5. 核心状态对象与所有者是什么？
6. 新增了什么 capability，也新增了什么 effect/risk？
7. 失败、取消、恢复与人工 steering 语义是什么？
8. 证据如何进入 context，如何失效？
9. 评测 claim、task、harness、budget 和 scorer 是否匹配？
10. 是否有 baseline、ablation、方差、broken-task audit 与真实 trace？
11. 它减少了什么复杂度，还是只是增加 scaffolding？
12. 如果模型能力再提升一代，这个机制仍然必要吗？

这十二问既过滤概念炒作，也避免因为某个项目“代码最容易读”就错把它当作能力上限。

18. 2026 能力前沿与研究雷达

深度卷：跨层张力、失败归因与前沿判断。

前沿判断先看真实产品与工作实践，再用论文、公开实现和标准解释机制。下表不是总榜：不同产品推进的是不同能力维度，且一手厂商材料仍带选择性披露。

18.1 Frontier Reference Cohort：产品事实优先，隐藏实现留白

这一 cohort 暴露出三条同时成立的路线：Codex 把重点推进到多 surface、并行与持续 steering；Claude 把重点推进到长任务 harness、可替换 runtime 边界与 evaluator；pi 证明前沿也可能来自删除固定功能、暴露深扩展点。Kimi 的价值在于 glass-box 可解释性。先进性不是 feature count，也不是 source count，而是特定任务与约束下的 verified capability frontier。

18.2 已成为结构变化

18.3 正在快速形成

Harness Science

研究对象从 prompt 变成 context、tools、state、permissions、recovery、observability 的组合；关键方法是 component-level editable surface、完整 trajectory 和 prediction-before-change。值得关注的是 Agentic Harness Engineering，它报告自动演进 harness 的收益主要来自 tools、middleware 和 long-term memory，而不是 system prompt。需要继续验证 held-out task、budget parity 和跨模型迁移，防止“自动 benchmaxxing”。

Learned Context Management

CompactionRL、AgeMem 等工作把 compact/store/retrieve/delete 变成 policy action，说明 context management 可能从外部 heuristic 逐步进入模型训练。风险是 policy 与某套 harness/tool schema 过拟合，且 memory corruption 会成为持久状态故障。

Training—Runtime Convergence

ToolVerse、Polar（及其被重写的前作 ProRL Agent）和生产 Agent trace 共同指向：训练环境会越来越像生产 runtime，生产 runtime 也越来越像数据采集与实验平台。这里是两条研究方向的汇合，不是把 Polar 与 ProRL 当作独立重复证据。未来关键资产不只是 model weights，而是可复现环境、tool contract、trajectory、verifier 和 rollout infrastructure。

Provenance-bearing Systems

Memory、retrieval、tool output、inter-agent artifact 和高风险决策开始共享同一问题：信息来自哪里、如何被转换、凭什么获得 authority。Typed memory、influence graph、effect receipt 和 trace propagation 正在汇合成统一 provenance plane。

18.4 仍需谨慎验证

Self-evolving Harness

自动修改 tools/middleware/memory 很有潜力，但容易被 eval leakage、judge bias 和局部 task 分布驱动。最低要求是 train/validation/test 隔离、冻结 budget、prediction log、revertibility、跨模型迁移和人工审计。

Fully Learned Memory Policy

端到端学习写/删 memory 可能优于规则，但错误具有跨时间复利。除 utility 外必须评 transition faithfulness、scope isolation、unlearning、bias contagion 和新模型兼容性。

Large-scale Decentralized Agent Networks

A2A 使跨 Agent 通信可行，不代表 decentralized swarm 已可靠。身份、授权、shared state、错误相关性、cascading failure、成本和 artifact verification 仍缺成熟解法。

Autonomous Verification

Agent reviewer 能扩大 review throughput，却可能与生成 Agent 共享模型偏差。确定性 oracle、异构 verifier、counterfactual tests 和 risk-based human review 仍不可替代。

18.5 最值得持续追踪的十二个问题

1. 模型原生 agentic training 会删除哪些 harness scaffolding？
2. learned compaction 是否能跨 harness/model 泛化？
3. retrieval benchmark 如何表达多条合法证据路径？
4. original benchmark 如何保持长期新鲜而不失去规模？
5. memory transition verifier 怎样避免自身 bias 被固化？
6. production trace 怎样在隐私约束下进入训练和 eval？
7. MCP stateless migration 会怎样改变 host lifecycle？
8. A2A delegation 如何获得可验证 identity 与 least privilege？
9. OpenTelemetry GenAI conventions 何时稳定到可跨产品比较？
10. multi-agent topology 能否根据任务特征在线自适应？
11. dynamic autonomy 如何避免把用户疲劳误学成信任？
12. verification capacity 能否跟上并行 Agent 的生成速度？

19. Kimi Code 作为 Glass Box：映射对象，不替代 Frontier Cohort

深度卷：Kimi Code 公共架构与面试答辩。

公开 Kimi Code 可以映射为下表。它的特殊价值是可沿源码追踪 ownership 和 control path；这是一种 epistemic advantage，不等于 product capability advantage。任何“比 Codex / Claude Code / pi 更先进或落后”的判断，都必须补同条件产品 contract、hands-on trace 与 controlled eval。

这说明公开仓库已经足以把 JD 中“模型之外关键系统”落到具体所有权边界；它没有证明公开代码就是 Moonshot 全部生产系统，也没有证明每个已出现的 feature 都代表当前最佳实践。详细源码路径见完整作战手册。

20. 系统化知识自检

深度卷：Kimi Code 公共架构与面试答辩。

不要求再做一个产品；目标是能在没有资料提示时，形成完整、无混淆的解释。

Model

• 为什么 OpenAI-compatible API 不等于语义兼容？
• reasoning effort、context、prompt cache 如何共同影响系统？
• 怎样区分模型缺陷与 harness 缺陷？
• Agentic post-training 为什么依赖稳定的 environment、trajectory 和 verifier？
• depth、width、experience scaling 各自受什么约束？

Context / State / Memory

• 三者分别解决什么时间尺度？
• 为什么 transcript 不能作为唯一事实源？
• compaction 的不变量和评测方式是什么？
• memory transition 的 coverage、preservation、faithfulness 是什么？
• evaluator bias 为什么会经 memory 跨时间传播？

Loop / Runtime

• Turn、Step、tool call 的边界是什么？
• cancel、retry、recover、replan、failover 有何不同？
• effect 已发生但 receipt 丢失时怎样恢复？

Tools / Environment

• 为什么 shell 是 process lifecycle，而不是字符串执行？
• 怎样定义 tool effect、并发冲突和权限？
• 大输出怎样在 user、model、journal、artifact 之间分配？

Multi-agent

• 哪类任务并行收益最大，哪类任务必然协调退化？
• correlated error 为什么比 agent 数量更重要？
• centralized orchestrator 的价值与瓶颈是什么？

Protocol / Identity / Observability

• MCP、A2A、ACP、LSP 各自标准化哪一段关系？
• MCP stateless 规范把哪些责任推回 host？
• A2A 通信成功为什么不代表 trust composition 成功？
• OpenTelemetry 通用语义与产品 domain events 怎样分层？
• Agent identity、user identity 与 delegated authority 有何区别？

Eval

• benchmark 为什么必须披露 harness 和 budget？
• outcome 与 trajectory 怎样一起评？
• 如何从真实 trace 构造合法回归集？

Safety / Product

• prompt policy 和 sandbox 各自是什么边界？
• 怎样降低 approval fatigue 而不牺牲安全？
• 什么指标能代表用户真正获得结果？
• prompt annotation 与 channel closure 有什么差别？
• autonomy 为什么应是 scope/capability/effect/horizon/budget 的向量？
• generation throughput 超过 verification capacity 后会发生什么？

Strategy

• 模型变强后哪些 harness 应删除？
• Agent 产品的长期护城河在哪里？
• 如何判断一个新热点是结构变化还是重命名？

若这些问题可以从“对象—机制—失败—证据—tradeoff”五个角度完整回答，就已形成稳定知识体系，而不是碎片化背诵。

21. 一手资料索引

Kimi / Moonshot

• Kimi Code 公开仓库最终复核快照 75395f6
• Kimi Code 模型配置
• Kimi K3 技术报告
• Kimi Code 更新日志

Frontier 产品与实践 Reference Cohort

• Codex CLI rust-v0.146.0
• OpenAI：Codex App Server
• OpenAI：Codex App、Parallel Agents、Skills、Automations
• OpenAI：Cross-device Live Steering
• Claude Code CLI v2.1.220
• Claude Code：Subagents
• Claude Code：Agent View
• Claude Code：Agent Teams
• Claude Code：Dynamic Workflows
• Claude Code：Goals
• Claude Code：Routines
• Anthropic：Managed Agents
• pi 正式 v0.83.0 README
• pi main 复核快照 c6eb628
• pi release v0.83.0

Harness 与长期 Runtime

• OpenAI：Unrolling the Codex Agent Loop
• OpenAI：Harness Engineering
• Anthropic：Long-running Agent Harness
• Anthropic：Harness Design for Long-running Apps
• Anthropic：Managed Agents / Brain and Hands
• Harness-Bench
• Claw-SWE-Bench
• Agentic Harness Engineering

Context 与 Memory

• Anthropic：Effective Context Engineering
• CompactionRL
• AgeMem
• Coding Agents are Effective Long-Context Processors
• ReasoningBank
• TrustMem
• MemIR
• Memory Contagion

Evaluation 与 Coding-Agent Benchmarks

• OpenAI：Coding Evaluation Audit
• OpenAI：Trustworthy Third-party Evaluations
• DeepSWE
• RoadmapBench
• SWE-Explore
• Agent Retrieval Bench
• RACE-bench

Agentic Training 与 Coordination

• ToolVerse
• ProRL Agent
• Polar
• Google Research：Scaling Agent Systems

Protocols 与 Observability

• MCP Architecture
• MCP 2026-07-28 Changelog
• A2A 1.0 Specification
• A2A Releases
• Agent Client Protocol
• OpenTelemetry GenAI Semantic Conventions

Security、Identity 与 Human Oversight

• Anthropic：Agent Containment
• OpenAI：Monitoring Internal Coding Agents for Misalignment
• NIST AI Agent Standards Initiative
• NIST AI Agent Security RFI Analysis
• OWASP Agentic Applications Top 10 2026
• AgentSecBench
• AgentDyn
• ARGUS / AgentLure
• Anthropic：Measuring Agent Autonomy
• Human Oversight of Agentic Systems in Practice
• Hedwig Dynamic Autonomy

Product 与 Work Transformation

• OpenAI：How Agents Are Transforming Work

知识更新方法：先分别记录 PUB / PRODUCT / TRACE / EVAL 四个事实面，再在独立的 capability 轴上比较 task envelope、horizon、state、orchestration、verification、security 与 economics。公开代码确认机制，不负责替产品排先进性；官方 contract 确认产品面，不负责补全闭源后端；trace/eval 才能约束真实行为与效果。永远区分已确认事实、推断和未知。