AI Agent 基础、本体与系统架构：从“会调用工具”到“可证明的执行系统”

研究与二次核验基线：2026-08-03（Asia/Shanghai）。本文是概念与架构参考手册，不是入门教程、学习计划或项目作业。目标是给出一套能够跨模型、框架和产品演进而保持稳定的语言，使所有后续讨论——context、tool、runtime、eval、security、multi-agent——落在同一组对象、状态、边界与不变量上。

Freshness 与证据契约

• 公开源码判断固定到核验时的不可变快照：Kimi Code 29c9e2ab（2026-08-03 07:42:09 UTC）、OpenAI Codex bb5054fe（2026-08-03）和 Pi c6eb6281（2026-08-03）；Kimi K3 资料固定到 7c5be959。源码链接尽量使用 commit，而不是漂移的 main。
• Claude Code、Pi 以及 Codex 产品文档是滚动 contract，本文核验于 2026-08-03；滚动文档只能证明核验时的公开产品语义，不能还原过去版本，也不能暴露其未公开后端。
• 四篇 2026 年 harness 研究均按核验日最新公开版本引用：Harness-Bench v1、Claw-SWE-Bench v1、AI Harness Engineering v1、Agentic Harness Engineering v4；它们都是 arXiv 原始预印本，不等于已通过同行评审的行业定论。
• OpenAI 与 Anthropic 数据属于官方工程报告或自有产品观测，能够证明其披露设置下的现象，不能替代独立复现，也不能无条件外推到 Kimi 或其他产品。
• NIST 资料是 2026-02-05 发布、征求意见期已于 2026-04-02 结束的 NCCoE concept paper，不是正式标准、推荐实践或合规要求。
• 文中的形式化对象、状态机和不变量属于本文从分布式系统、控制与证据边界推导出的分析模型；除明确标注外，不声称它们是某家厂商的官方术语或已发布标准。

两个正交轴：可验证性不等于先进性

研究 Coding Agent 最容易犯的错误，是把“我能读到多少实现”当成“它有多强”。这两个问题必须完全拆开：

Capability 本身也不是一个总分，而应至少写成：

FrontierVector = (
  environment_fidelity,
  task_horizon,
  verified_outcome,
  recovery_robustness,
  context_continuity,
  parallelism_and_delegation,
  oversight_and_authority,
  latency_cost_resource_efficiency
)

因此存在四类完全不同的对象：

这意味着：

• 公开源码是 glass-box evidence，不是冠军奖杯。它能回答 scope、event、tool、persistence 如何实现，不能单独证明真实任务更长、更稳或成功率更高；
• 产品采用与运行时长是需求/使用信号，不是 correctness。并行运行 60 agent-hours 也可能包含失败、重试和低价值工作；
• benchmark 排名是配置化结果，不是产品本体属性。必须同时固定 model、harness、environment、budget、verifier 和版本；
• 官方 contract 是可依赖的外部语义，不是私有拓扑图。Codex Cloud 的调度/模型服务、Claude Code 的私有 harness/backend、Kimi 内部生产系统均不得从公开 CLI 或文档脑补；
• Pi 的极简与可扩展是架构选择，不自动等于能力领先或落后。若缺少同口径 outcome eval，只能评价其机制与可组合性，不能排 capability 名次。

本文采用以下 claim grammar，后文所有比较都应能改写成其中一种：

Mechanism claim : "公开源码在 commit Y 实现了 X。"
Contract claim  : "核验日的官方文档承诺/描述了外部语义 X。"
Trace claim     : "产品观测在 population P、window T 中记录到 Y。"
Eval claim      : "联合配置 C 在 task set D、budget B、verifier V 下得到 Z。"
Inference       : "基于以上证据，本文推断 Q；未知项是 U。"

不得从第一句直接跳到“所以它最先进”。本文把 Codex、Claude Code 用作 frontier 产品/真实实践信号，Pi 用作 minimal-harness 与可扩展 contract 信号，Kimi 用作 glass-box anatomy sample；它们不是同一证据类型，也不在本章做伪精确总排名。

0. 先给结论：Agent 的本质不是“自主”，而是“受约束地闭环改变环境”

一个系统是否是 Agent，不取决于它有没有聊天界面、是否调用了 LLM、是否使用 function calling，也不取决于厂商是否把它命名为 Agent。真正的判据是：

系统是否围绕一个目标，在部分可观测且会变化的环境中，依据新证据动态选择下一行动，并在明确的权限、资源与停止边界内持续闭环，直到外部验证器确认完成、系统确认不能继续，或控制权交还给人。

这一定义包含五个不能删掉的性质：

1. 目标性：存在想让现实达到的状态，而不只是生成某段文本；
2. 闭环性：后续决策依赖行动后的新观察，而不只是预先生成完整脚本；
3. 选择性：路径、工具或停止时机至少有一部分由模型策略根据状态决定；
4. 作用性：行动能读取或改变模型之外的环境；
5. 边界性：权限、预算、验证、停止与人工接管不由模型任意定义。

因此最小系统等式不是 LLM + tools，而是：

Agent System
  = Goal Contract
  + Model Policy
  + Harness / Control Plane
  + Context and State Projection
  + Tool and Environment Boundary
  + Durable Runtime
  + Evidence and Verification
  + Authority and Resource Boundary
  + Human Interface

其中，LLM 主要提供一个高维、概率性的策略近似器；真正让它成为可靠执行系统的是模型之外的状态所有权、作用边界、证据链和控制闭环。2026 年 Harness-Bench v1 在 5,194 条轨迹中观察到显著的 model–harness 配对效应；Claw-SWE-Bench v1 更显示同一 GLM 5.1 在 minimal adapter 与 full adapter 下从 19.1% 到 73.4%。这并不证明“harness 比模型更重要”，而是支持 Agent capability 应在联合系统配置层报告，不能只归因给单个模型名。两项数字均为论文作者在其 benchmark、adapter 和预算设定下的结果。

1. 研究对象与边界

1.1 本文讨论的不是哪些东西

本文不把以下对象直接称为 Agent：

• 单次补全、分类、摘要或问答；
• 固定 DAG 中一个由 LLM 执行的节点；
• 只能建议、不能观察执行结果的代码补全器；
• 通过自然语言包装的确定性脚本；
• 调用一次工具后必然终止、且不根据结果调整的 function-calling 请求；
• 只有“记住聊天历史”，没有外部目标状态与完成判定的 chatbot。

它们可以是 Agent 的组件，也可能具有局部 agentic behavior，但不能因为包含 LLM 就获得完整 Agent 语义。

1.2 Agent 的边界不是模型进程的边界

Anthropic 在 2026 年把 Agent 拆为 model、harness、tools、environment 四部分，并强调任一层配置不当都能改变行为与风险；其工作定义是“模型自行指导过程与工具使用，而不是遵循固定脚本”Trustworthy agents in practice。本文在此基础上再补三层：durable runtime、verification、human/authority boundary。原因是：

• model 不拥有外部事实；
• tool 不拥有任务生命周期；
• harness 不必拥有持久化 worker 与资源调度；
• environment 不知道任务为何完成；
• UI 不应成为状态真相源；
• verifier 不应与被验证的生成动作完全同源。

所以“Agent 在哪里”没有单一进程答案。Agent 是一组跨边界协同维持不变量的系统关系。

1.3 Agenticness 是向量，不是一条营销分界线

可用以下向量描述系统的 agentic 程度：

Agenticness = (
  decision_scope,       # 模型能选择多少路径和动作
  action_surface,       # 能触达多少外部能力
  temporal_horizon,     # 能独立运行多久、跨多少状态
  feedback_adaptation,  # 后续动作多大程度依赖新证据
  delegation_depth,     # 是否能产生和管理子任务/子代理
  authority,            # 被授予的实际权限与影响范围
  reversibility,        # 作用是否容易撤销
  oversight_distance    # 人类检查点与动作之间的距离
)

两个系统都可以叫 Agent，但风险完全不同：只读代码检索 Agent 与能改代码、推送分支、触发部署的 Coding Agent，模型可能相同，authority 和 action surface 却相差几个数量级。2026 年 Anthropic 的真实使用研究也说明，turn duration 只是 autonomy 的不完美代理；它受任务难度、模型速度、subagent、用户信任和产品设计共同影响，不能把“运行更久”直接解释为“能力更强”Measuring AI agent autonomy in practice。

2. 精确本体：系统里究竟有哪些对象

2.1 目标层对象

Intent → Goal 不是普通文本解析，而是 任务契约编译。同一句“修复登录问题”至少缺少：目标环境、可修改范围、回归要求、数据迁移约束、是否允许部署。模型可以发现缺口，但无权把高影响偏好补成用户授权。

2.2 过程层对象

2.3 决策与作用层对象

典型链条必须写成：

proposal -> intent -> admission -> action -> effect -> receipt -> observation

把任何相邻两项合并，都会制造具体缺陷：把 intent 当 effect 会重复执行；把 receipt 当 correctness 会误报完成；把 observation 当事实会被陈旧输出或 prompt injection 污染。

2.4 证据与记录层对象

核验快照中的 Kimi Code agent-core-v2 公开设计明确把 telemetry 注册表作为稳定 wire data，要求事件名和字段模式化、禁止提示词和路径进入业务 telemetry，并将 append-log、atomic document、blob 按访问模式拆分；这些不是“日志风格”，而是状态与证据本体的实现约束agent-core-v2 AGENTS.md，29c9e2ab。这只能证明公开快照的代码 contract，不证明未公开生产部署与其完全一致。

2.5 身份、能力与责任对象

NIST 2026 年的软件与 AI Agent 身份 concept paper 把 identification、authorization、auditing、non-repudiation 与 prompt injection 同时列为拟议项目问题，支持“知道是哪个 Agent”之外还应追问它代表谁、能做什么、能力从何而来、是否可再委派NIST NCCoE concept paper。这是一份已结束征求意见的概念文件，不是 NIST 标准或规范性要求；本文后半句是系统设计推论，不是 NIST 已作出的正式结论。

3. 一个可计算的 Agent 形式化模型

3.1 从 POMDP 到工程 Agent

经典 POMDP 可以表示为 (S, A, T, O, Ω, R, γ)，但工程 Agent 不能只优化 reward：它必须处理硬约束、权限、不可逆 effect、任务契约、人工接管、持久化与外部验证。因此定义一个运行实例：

Episode A = <
  G,      # goal contract: goals, success criteria, preferences
  C,      # hard constraints
  W,      # world/environment state, only partially observable
  X,      # internal durable task/control state
  M,      # governed cross-scope memory
  K,      # context projection function
  πθ,     # probabilistic model policy
  P,      # deterministic admission/policy function
  T,      # environment transition function
  Ω,      # observation/receipt function
  δ,      # journal event reducer
  V,      # verifier family
  B,      # budget/resource state
  I       # identity, authority and delegation state
>

在第 t 个 step：

c_t   = K(G, C, X_t, M, recent_events, available_tools, B_t, I_t)
u_t  ~ πθ(c_t)                                  # model proposal
d_t   = P(u_t, C, X_t, B_t, I_t)                # admission decision
a_t   = materialize(u_t, d_t)                    # admitted action or no-op
W_t+1 ~ T(W_t, a_t)                              # external transition
r_t   = receipt(a_t, W_t, W_t+1)                 # execution evidence
o_t+1 = Ω(W_t+1, r_t)                            # partial observation
e_t   = event(u_t, d_t, a_t, r_t, o_t+1)         # durable fact
X_t+1 = δ(X_t, e_t)                              # deterministic reduction
v_t   = V(G.criteria, C, X_t+1, evidence_t)       # completion judgment

关键点不是公式复杂，而是所有权清楚：

• πθ 可以提出动作，不能决定 P；
• P 可以准入动作，不能声称 T 已成功发生；
• receipt 证明执行事实，不自动满足 V；
• δ 从 durable events 恢复系统状态，不重新调用模型“猜发生了什么”；
• V 给出 satisfied / unsatisfied / violated / unknown，而不是只有布尔 pass；
• 人工介入可以改变 G/C/I/X，但必须形成新事件而非偷偷改 prompt。

3.2 五类状态不能混在一个 messages[]

W_t  world state      : 文件、Git、进程、数据库、远端服务、真实部署
X_t  control state    : turn/step、预算、pending effects、jobs、cancel、goal
B_t  belief state     : Agent 当前关于世界的带置信度认识
C_t  context snapshot : 某次模型调用实际看到的 B/X/history 投影
U_t  presentation     : 用户界面的 transcript、progress、approval 状态

关系是 W → observation → B → context projection → C，而不是 messages = truth。UI U 也只是投影。一个工具输出被截断时：

• W 中命令可能已执行完；
• receipt 中应记录退出码、artifact pointer、截断元数据；
• B 只能声称“看到了输出前 64 KiB”；
• C 可能只注入摘要；
• U 可允许用户打开完整 artifact。

任何层如果把截断后的文本宣称为完整事实，都破坏了 epistemic integrity。

3.3 合法状态机

一个任务状态至少包含：

CREATED
  -> SPECIFYING
  -> READY
  -> RUNNING
       -> WAITING_MODEL
       -> ADMITTING_ACTION
       -> WAITING_EFFECT
       -> RECONCILING
       -> VERIFYING
       -> WAITING_HUMAN
       -> RUNNING
  -> SUCCEEDED | FAILED | CANCELLED | EXHAUSTED | BLOCKED

CANCELLED 只表示系统不再主动推进；它不表示 W 恢复到初始状态。FAILED 也不表示所有 effect 都失败。状态机必须允许“任务失败但环境部分改变”。

3.4 Safety 与 liveness 不变量

安全不变量描述“永远不能发生”：

□ not(effect_without_admission)
□ not(authority_escalation_from_untrusted_observation)
□ not(completed_without_fresh_evidence)
□ not(retry_unknown_effect_without_reconciliation)
□ not(secret_material_entering_untrusted_sandbox)

活性不变量描述“若条件成立最终应推进”：

admitted + runnable + budget_available
  => eventually(receipt | explicit_timeout | cancellation)

candidate_complete + verifier_available
  => eventually(succeeded | incomplete | violated | unknown)

仅有 safety 会让系统什么都不做；仅有 liveness 会让系统为了前进突破边界。成熟 Agent runtime 必须同时回答：哪些状态不可达，以及合法工作为什么不会永久卡死。

4. Agent、workflow、copilot、automation、harness、runtime、environment 的严格区分

4.1 一张判别表

4.2 Automation 与 workflow

Automation 是触发器到动作的确定性映射：

event -> rules -> action

Workflow 是事先定义的控制流拓扑：

start -> node A -> condition B -> node C/D -> end

节点内部可以使用 LLM，但只要控制流、可用动作和完成路径仍由代码预先决定，它仍是 workflow。Anthropic 的经典区分是：workflow 通过预定义代码路径编排 LLM 和工具；agent 让 LLM 动态指导过程与工具使用Building effective agents。

4.3 Copilot 与 Agent

Copilot 的本质不是“弱 Agent”，而是 任务闭环所有权在人：

• 人选择下一处代码、决定是否接受、执行最终验证；
• 模型生成候选、解释或局部 patch；
• 即使模型能力很强，只要没有取得 task loop 所有权，仍是 copilot。

Agent 则至少在一段授权范围内拥有下一行动和停止时机的选择权。界面可相同，区别在 control ownership。

4.4 Agent 与 workflow 的组合不是二选一

四种合法组合：

1. workflow 包含 agent node：固定审批流中的“分析异常并提出处理方案”；
2. agent 调用 deterministic workflow：Coding Agent 触发标准 CI/CD pipeline；
3. workflow 管理多个 agent episode：批量 issue 修复，每项由 Agent 处理；
4. agent 生成 plan，workflow engine 执行受限 DAG：概率规划、确定性执行。

最可靠的产品通常是 hybrid：把开放世界判断留给模型，把权限、生命周期、关键业务转移与可判定检查留给确定性系统。

4.5 Harness 与 runtime：行业最常混淆的边界

“Harness”在行业里有宽、窄两种用法：

• 宽义：模型之外让 Agent 工作的一切，包括 loop、tools、state、sandbox、eval；
• 窄义：把模型包装为某种行为策略的控制层，包括 instructions、context projection、tool schemas、loop policy、retry/compaction/verification策略。

本文采用窄义，并把长期执行底座单列为 runtime：

Harness answers:
  What should the model see?
  What may it propose?
  How is proposal translated, checked and fed back?
  What model-specific assumptions are encoded?

Runtime answers:
  Which episode runs where and when?
  Who owns lifecycle, persistence, concurrency and resources?
  How does it survive crash, cancellation and worker loss?
  How are effects reconciled and sessions resumed?

边界测试：更换模型、prompt、context policy、tool presentation 后仍可复用的是 runtime；更换 worker、sandbox、storage 后仍表达同一模型行为策略的是 harness。

Anthropic 2026 年 Managed Agents 将 session（append-only event log）、harness（调用模型并路由 tool calls 的 loop）、sandbox（执行环境）虚拟成可替换接口，正是这一分离的公开工程例证；其解耦后 harness 可通过 wake(sessionId) 恢复，sandbox 可独立重建，且 p50 TTFT 下降约 60%、p95 下降超过 90%Scaling Managed Agents。这些数字是该实现的结果，不应外推成所有系统的普遍收益。

4.6 Environment 不是“工具列表”

Environment 是 action 真正落地的状态空间，包括：

• repo、filesystem、Git index/worktree/remote；
• shell、PTY、process tree、network、package manager；
• IDE/LSP/build/test/CI；
• database、cloud、deployment、secret stores；
• 人、组织流程与其他 Agent；
• 时间本身：文件可在观察后被别人修改，服务可在验证前漂移。

Tool 只是 Agent 访问 environment 的 capability adapter。工具返回 ok 不代表目标环境达到期望状态；工具没有暴露的环境状态也仍可能改变任务结果。

4.7 三个常见伪装

伪装一：自然语言 workflow 被叫 Agent。 模型只负责抽取参数，所有路径固定；应称 LLM-powered workflow。

伪装二：单次 function call 被叫 Agent。 没有基于结果继续选择；应称 tool-using inference。

伪装三：带聊天 UI 的 automation 被叫 Agent。 用户对话只是配置脚本；应称 conversational automation。

这些系统并不低级。错误在于用错名词后套用错误的可靠性方案：固定 workflow 应做状态机覆盖与幂等测试；Agent 还必须做轨迹评测、belief/evidence 审计和开放失败归因。

5. 三个嵌套闭环与五种时间尺度

5.1 Step loop：局部认知—行动闭环

observe -> project context -> propose -> admit -> execute -> receive -> update belief

目标：每一步都基于新的、可关联证据推进，而不是重复猜测。

主要不变量：

• proposal 与 effect 分离；
• tool call 与 receipt 由 stable call/effect ID 关联；
• 未知 effect 先 reconciliation；
• observation 标明来源、新鲜度、截断与可信域；
• 同一步中的并发动作不能违反读写冲突约束。

5.2 Task loop：目标—验证闭环

compile goal -> plan/execute -> accumulate evidence -> verify
      ^                                            |
      +---------- replan / clarify / recover ------+

目标：不是“让模型停止生成 tool calls”，而是让 success criteria 得到外部证明。

主要不变量：

• assistant final message 只是控制流信号，不是完成证明；
• plan 可变，goal/constraint 的改变必须显式；
• verifier 必须知道验证覆盖范围与未验证部分；
• budget exhaustion、blocked、failed、cancelled 不得伪装成 success。

5.3 Learning loop：真实失败—系统进化闭环

production trace
  -> privacy-safe episode package
  -> first bad transition / failure cohort
  -> reproducible eval
  -> model or harness hypothesis
  -> ablation
  -> shadow/canary/rollout
  -> population evidence

目标：让一次失败变成可证伪的改进，而不是给 system prompt 再加一句话。

主要不变量：

• 先定义 claim，再定义 eval；
• 保留 model、harness、environment、budget 配置；
• outcome 与 trajectory 同时分析；
• 改动必须有预测、对照、回归面与退出条件；
• 线上 trace 不是未经治理即可训练的 memory/data。

Agentic Harness Engineering v4 把 component、experience、decision observability 配成一个可证伪的 harness 演进闭环；其消融把报告的主要增益定位到 tools、middleware 与 long-term memory，而非 system prompt。该结论是作者在特定 benchmark 与演化过程中的归因，仍属预印本证据，不能直接推出“所有 harness 优化都应优先改工具”，并必须防止自动演进对评测集过拟合。

5.4 三个闭环如何嵌套

外环不能实时代替内环：不能因一次 tool error 就在线改模型权重。内环也不能代替外环：运行时 retry 可能让某次成功，却掩盖系统性 provider 错误。

5.5 五种时间尺度与所有权

“状态必须有时间尺度”是架构判断，不是文档分类。例如 model request 的 retry counter 不应成为 session memory；用户对架构的长期偏好也不应被 tool output 截断策略覆盖。

5.6 频率、延迟与一致性

每个尺度还对应不同一致性需求：

• model stream 追求低延迟，可允许 UI 最终一致；
• effect ledger 必须强关联，不能把两个 call 的输出串错；
• durable journal 可 append 后异步派生 transcript，但 completion gate 必须看已提交证据；
• telemetry 允许采样和延迟，不得反向成为恢复真相源；
• learning loop 可批处理，但 eval 配置必须不可变、可追溯。

6. 完整系统架构：五个平面，而不是一条 while loop

6.1 五平面模型

1. Intent / Product Plane：意图解释、任务契约、交互、人工接管；
2. Cognitive / Control Plane：context、model policy、planning、admission、budgets、loop；
3. Execution / Environment Plane：tool adapters、sandbox、process、filesystem、remote systems；
4. State / Evidence Plane：journal、reducer、artifacts、trace、verifier、audit；
5. Learning / Governance Plane：telemetry、failure attribution、eval、rollout、policy/model/harness evolution。

Identity、authority、privacy、resource governance 横穿五个平面，不能作为“安全插件”事后追加。

6.2 组件与数据流

6.3 一次 Coding Agent step 的端到端序列

6.4 深模块与稳定接口

好的 Agent 架构不是微服务数量多，而是每个边界隐藏复杂度：

ModelRequester.request(ContextSnapshot) -> ModelEpisode
PolicyGate.admit(ToolIntent, CapabilitySet, Budget) -> AdmissionDecision
ToolExecutor.execute(AdmittedAction) -> EffectReceipt
Journal.append(DomainEvent) -> SequenceNumber
Reducer.reduce(State, DomainEvent) -> State
Verifier.verify(CriterionSet, EvidenceBundle) -> VerificationReport
Runtime.wake(SessionId) -> Lease
Sandbox.provision(ResourceSpec) -> EnvironmentHandle

接口不暴露 provider stream 拼接、PTY 背压、blob 脱水、journal repair、sandbox placement 等内部复杂度。OpenAI 2026 年对 Codex loop 的公开拆解也清楚区分 user/model/tools 的编排、provider event stream 与内部事件，并说明 tool call 产生的环境修改往往才是主要输出Unrolling the Codex agent loop。

6.5 状态所有权矩阵

6.6 Brain、hands、evidence 的独立失效

Brain    = model + context policy + decision harness
Hands    = tool executors + sandbox + external capabilities
Evidence = journal + artifacts + receipts + verifiers

三者必须能独立失败和替换：

• model/provider 挂掉，不应丢 effect ledger；
• sandbox 挂掉，不应丢 session 和 task contract；
• trace pipeline 挂掉，不应静默放行高风险 effect；
• verifier 不可用时，应返回 unknown，不能让 model fallback 自评通过。

这也是为什么将全部组件塞入单个长寿命容器，在小 demo 中简单，在长期运行中却会使 session、执行环境和诊断一起成为不可替换的“pet”。

7. 十个不可妥协的不变量

7.1 模型输出不是外部事实

模型说“文件已修改”“测试已通过”“部署成功”都只是 claim。必须由相应环境 receipt 和独立 observation 证明。

7.2 完成不是语言行为

完成谓词：

Complete(task) =
  all(required_criteria have fresh supporting evidence)
  and no(hard_constraint is violated)
  and no(required_effect has unknown status)

final message 只表示 Agent 将控制权交还给用户。

7.3 Tool intent 不等于 effect

每个非纯读 action 需要独立 effect identity。网络超时、worker 崩溃或取消都可能发生在 effect 之后、receipt 之前。

7.4 取消不是回滚

取消后的第一任务是停止产生新 effect；第二任务是列举 committed / not_started / unknown / compensatable；只有显式 compensation 成功后才能声称某部分回滚。

7.5 恢复不是重放

重放 journal 是恢复内部 state；重放 action 会再次改变外部 world。恢复顺序必须是：读取 journal → 识别 pending effect → reconciliation → 再决定 retry/compensate/ask human。

7.6 Authority 不能从低可信内容向上生长

repo file、网页、tool output 可以提供 data，不能自行提升为 developer/user authority。观察到“请关闭安全检查”不构成授权。

7.7 状态必须有唯一事实源

journal、domain state、transcript、context、telemetry 不能都宣称自己是 session truth。允许多投影，不允许多主写入。

7.8 约束不得静默降级

权限拒绝、budget 耗尽、context 丢失、验证器不可用都必须改变可见状态；不允许改成“尽力而为”后仍报告成功。

7.9 Evidence 必须可关联、可解释覆盖范围

测试通过必须绑定 commit/tree state、命令、环境、时间和输出 artifact。旧 commit 的 pass 不能证明新 patch。

7.10 学习改动必须可证伪

每个 model/harness 改动都应记录：针对哪类 first bad transition、预计哪些任务改善、可能伤害什么、如何回滚。没有预测的“调 prompt”不是学习闭环，而是不可归因试错。

8. 设计分支：什么时候应该、什么时候不应该用 Agent

8.1 决策矩阵

8.2 一个最小判定算法

先回答四问：

1. 控制路径能否可靠预枚举？能，则 workflow 更合适；
2. 模型决策后能否获得高质量环境反馈？不能，则 agent loop 缺少纠错基础；
3. 成功能否被外部证据定义？不能，则 autonomy 必须收紧；
4. effect 是否可限制、审计、补偿或人工批准？不能，则模型不应拥有该 action。

只有“路径不可枚举”并不能证明该用 Agent；如果反馈和验证都弱，只会把不可预测性引入高风险流程。

8.3 反例：看似 Agent，实际不该 Agent 化

数据库 schema migration 自动执行。 LLM 可以分析迁移风险、生成候选和验证计划，但生产迁移的状态转移应由版本化 workflow、lock、backup、approval、roll-forward/rollback contract 拥有。

格式化整个仓库。 路径与验证确定，直接跑 formatter；让 Agent 逐文件决定只会增加成本和方差。

法律/财务最终审批。 Agent 可组织材料、发现冲突、解释规则；最终 authority 与不可逆 effect 应留在有责任主体的审批流程。

8.4 反例：看似 workflow，实际 Agent 更有价值

陌生代码库根因定位。 文件选择、假设生成、实验设计、结果解释无法预先固定；有 build/test/log 反馈，适合 Agent task loop。

依赖升级后的多语言修复。 具体 breakage 和修复路径由真实编译错误决定；可用确定性 CI 作为 verifier。

8.5 应该把确定性放在哪里

确定性系统应拥有：

• identity、capability、permission；
• lifecycle、budget、timeout、cancel propagation；
• schema validation、path/resource boundary；
• effect ledger、idempotency/reconciliation；
• journal versioning、reducer、migration；
• mechanically decidable success criteria；
• rollout、rate limit、privacy redaction。

模型适合拥有：

• 意图中低风险歧义的解释；
• 搜索方向、假设、计划和工具选择；
• 非结构化 evidence 的语义综合；
• 在明确边界内的局部恢复策略；
• 判断何时信息不足并提出高价值澄清。

设计原则不是“凡是能写代码的都确定性”，而是：把可判定的约束编译成机制，把不可枚举的判断交给模型；永远不要让模型同时创造规则、执行动作并验证自己。

9. 失败不是“模型答错”：按首次失真的状态转移归因

9.1 First bad transition

最终错误通常不是根因。定义一条轨迹：

τ = (x_0, u_0, d_0, a_0, r_0, o_1, x_1, ... , verdict)

first_bad_transition 是第一个使“成功仍可在既定预算和边界内合理达到”这一性质失真的事件。它可能早于最后报错几十步：

• context compiler 省略了用户否决的方案；
• tool schema 让模型无法表达正确参数；
• executor 把 stderr 截断成看似成功；
• stale test result 被当作新 patch 的证据；
• retry 在 effect unknown 时重复写入；
• verifier 只覆盖 happy path；
• UI 把 waiting approval 显示成 still running，导致用户重复提交。

归因目标不是找到“最后一个失败组件”，而是找到最早可干预、且反事实修改后能改变结果的责任边界。

9.2 按边界划分的失败分类

9.3 可恢复性不是 error message 属性

错误是否可 retry 取决于三件事：

Retryable(error, action, world) =
  error_is_transient
  and effect_status in {not_started, known_idempotent}
  and retry_budget_available

同一个 ECONNRESET：

• 读请求可直接 retry；
• 带 idempotency key 的创建请求可查询后 retry；
• 无幂等协议的远端部署请求必须先 reconciliation；
• 本地 shell 在 kill acknowledgement 前可能仍有子进程，不能假设已停止。

因此 provider error taxonomy、tool effect taxonomy 和 task recovery policy 必须分层，不能用一个 retry: 3 覆盖。

9.4 观测未知性必须是一等状态

推荐 effect 状态：

PROPOSED -> ADMITTED -> STARTED
STARTED -> COMMITTED | NOT_COMMITTED | UNKNOWN
UNKNOWN -> COMMITTED | NOT_COMMITTED | NEEDS_HUMAN
COMMITTED -> VERIFIED | EFFECT_ONLY | COMPENSATED

UNKNOWN 不是普通失败的同义词，而是禁止盲目重试的保护状态。

10. 可观测性：让状态、因果、边界和证据可还原

10.1 四个问题

任何一条失败轨迹都应能回答：

1. What happened? 哪些事实按什么顺序发生；
2. Why this decision? 当时模型看到了什么，控制面放行/拒绝了什么；
3. What changed in the world? 哪些 effect 确认、未知或已补偿；
4. Why this verdict? verifier 使用了哪些新鲜 evidence，覆盖和盲区是什么。

如果只能重放聊天文本，以上四问通常都答不全。

10.2 稳定身份链

最小关联链：

product_release_id
  -> task_id
    -> session_id
      -> turn_id
        -> step_id
          -> model_request_id
          -> tool_call_id
            -> effect_id
              -> artifact_id / receipt_id
        -> verifier_run_id

并行或 subagent 场景还需要 parent_task_id / delegated_by / principal_id / capability_grant_id。所有 ID 应在边界创建一次、向下传播，而不是各层根据时间戳猜关联。

10.3 最小 domain event envelope

{
  "event_id": "evt_...",
  "event_type": "effect.receipt",
  "schema_version": 3,
  "occurred_at": "...",
  "recorded_at": "...",
  "sequence": 184,
  "task_id": "task_...",
  "turn_id": "turn_...",
  "step_id": "step_...",
  "principal_id": "agent_...",
  "causation_id": "tool_call_...",
  "correlation_id": "effect_...",
  "config_fingerprint": "...",
  "payload": {
    "status": "committed",
    "duration_ms": 923,
    "output_artifact_id": "artifact_...",
    "truncated": true
  }
}

内容敏感数据与可关联元数据要分离。不能为了调试把源码、prompt、token、绝对路径和用户信息直接进入低治理 telemetry。

10.4 Trace 不是 journal

Journal: ordered domain facts; recovery correctness first
Trace:   causal spans/events; diagnosis and performance first

journal 允许派生 trace，trace 不应成为唯一恢复状态。采样 trace 可以丢，journal 的关键 effect fact 不可以丢。反过来，journal 有顺序，不一定有完整 wall-clock latency、cross-service parentage 和采样维度。

10.5 三层指标树

Outcome

• criterion satisfaction rate；
• verified completion、false completion、unknown verdict；
• constraint violation、human rejection、rollback/compensation rate。

Trajectory

• first bad transition 分布；
• useful step ratio、repeated action、replan、clarification；
• context acquisition recall、stale observation、effect unknown；
• verifier coverage、evidence freshness。

Efficiency / reliability

• task latency、time-to-first-action、time-to-verdict；
• tokens/cost/tool time、cache hit、sandbox utilization；
• retry/reconcile/crash-resume/cancel acknowledgement；
• p50/p95/p99，且按 task cohort、model、harness、environment 分层。

只看 pass rate 会把昂贵、脆弱、重复运行方差大的系统误判为优秀；只看 token/cost 又会奖励提前放弃。

10.6 可观测性本身也有边界

• 记录 chain-of-thought 可能提高诊断能力，也带来隐私、保留和安全成本；
• monitor 不是 verifier，发现异常不代表能证明所有安全；
• sampled telemetry 无法证明“从未发生”；
• LLM judge 可做语义分桶，不能替代可执行 oracle；
• trace schema 过细会制造高成本和泄露面，过粗则无法定位 first bad transition。

OpenAI 2026 年公开的内部 coding-agent monitor 在数千万轨迹上做低延迟行为审查，并明确承认开放分布下 false-negative 仍难量化、监控只是一层 defense-in-depth；这是“可观测性不能被宣传成保证”的重要现实例子How we monitor internal coding agents for misalignment。

11. 2025–2026 一手证据：哪些结构已稳，哪些结论仍不应过度外推

11.0 Freshness 核验账本

“已核验”表示正文陈述与上述不可变版本或官方页面一致，不表示厂商自报数字已获第三方复现，也不表示预印本已通过同行评审。

11.1 用 contract、trace 与 eval 校准 Codex / Claude Code / Pi / Kimi

“看起来先进”必须拆成三类证据：

Product contract  -> 它允许用户依赖什么外部行为？
Trace / practice  -> 真实人群和真实运行中出现了什么行为分布？
Eval / outcome    -> 在可比较条件下，是否完成了被 verifier 接受的任务？

其中 contract 可通过公开文档、协议与客户端源码核对；trace 揭示真实分布但缺少反事实；eval 最接近 capability claim，但只有在完整披露联合配置与 verifier 时才可比较。四个样本的证据并不对称：

这些材料给出的正确阅读是“不同证据拼出不同侧面”，不是给四个产品算一个加权总分：

• OpenAI 的 2026-06 研究称，在 0.1% 随机个人用户样本中，80.6% 曾请求过由 LLM judge 估计超过 30 分钟人类工时的任务，70.2% 超过一小时，25.6% 超过八小时；内部日活用户 99 分位在 2026-06 经常产生超过 60 小时/日的并行 Codex agent turns官方研究。这是 task-demand / adoption / parallelism signal；估计 horizon 不是运行时间，更不是 verified success。
• Claude Code 的产品文档证明 session transcript、file checkpoint、compaction、subagent context isolation 和 permission/sandbox 外部语义；autonomy study 证明特定人群的交互分布变化。两者合并仍不能揭示私有 backend，或证明每个长 turn 完成了用户目标。
• Pi 的源码与 RPC/event/session contract 使机制层验证成本很低，但缺失同口径 trace/eval 时，最诚实的结论是“可验证、可组合、适合机制研究”，而不是“最先进”。
• Kimi 的公开 v2 给本岗位提供最贴身的代码解剖样本；它之所以重要，是 可将抽象本体落到真实所有权路径，不是因为 public source 本身构成能力证据。

11.2 可支持结构判断的多源一致证据

判断一：Agent 性能应按 model–harness–environment 联合配置报告

• Harness-Bench v1：106 个 sandboxed tasks、5,194 条轨迹；作者观察到 completion、process quality、efficiency 和 failure behavior 随 model–harness 配对显著变化，并提出 execution-alignment failure；
• Claw-SWE-Bench v1：作者报告同一 GLM 5.1 因 adapter 从 19.1% 到 73.4%，固定模型时 harness 选择影响 27.4 个百分点；
• AI Harness Engineering v1：概念论文将 capability 形式化为 model–harness–environment system，并提出 task specification、context selection、tool access、project memory、task state、observability、failure attribution、verification、permissions、entropy auditing、intervention recording 共 11 项 harness 责任；其受控 validation task 主要展示 episode package 随 harness level 的证据结构变化，不构成大规模性能验证。

正确结论：报告 Agent 能力必须同时披露 model、harness、environment、budget 和 verifier。错误结论：“模型已不重要”——Claw-SWE-Bench 同样测到 model choice 有 29.4 个百分点影响。

判断二：长期 Agent 应显式分离 session、harness、execution environment 的生命周期与失效域

Anthropic Managed Agents 公开了 session log、stateless harness、sandbox 三接口，并说明耦合设计会让 container failure 同时表现为 session/harness/network 问题。此处可泛化的是 独立生命周期和失效域；其延迟收益数值只属于特定实现。

判断三：现实自治是人—模型—产品共同形成的变量，不能由单一 duration 代表

Anthropic autonomy study 发现 Claude Code 99.9 分位 turn duration 在三个月内从不足 25 分钟升到超过 45 分钟，经验用户同时更常 auto-approve、也更常 interrupt。可泛化的判断是：oversight 从逐动作批准迁移到抽样监控与主动 steering；不能把 duration 单独当作能力或安全指标。

判断四：至少在高吞吐 Coding Agent 案例中，环境、机械约束和反馈闭环成为主要工程杠杆

OpenAI Harness engineering 的 2026 年内部产品实验强调 repository knowledge system of record、agent legibility、机械执行架构不变量、观测反馈和 entropy cleanup。它是强工程案例，不是同行评审普遍规律；但与 Kimi JD 的“模型之外关键系统”高度同向。

判断五：Identity 与 delegated authority 值得作为独立控制面，而不能从通信协议隐含获得

NIST 2026 concept paper 把 identification、authorization、auditing、non-repudiation 与 injection mitigation 放在同一拟议问题域。它不是已发布标准；“多 Agent 协议解决通信但不自动解决 authority 与 accountability”是本文据此结合系统边界作出的推论。

11.3 正在形成、但仍应保留不确定性的方向

11.4 证据阅读纪律

对任何 2026 新结论，必须问：

1. 评的是 model、harness 还是联合配置？
2. environment 与 task contract 是否相同？
3. budget、effort、turn、token、cost、time 是否固定？
4. verifier 是否真正覆盖任务语义？
5. 是 outcome 提升还是仅 process 变好？
6. 是否重复运行，方差如何？
7. 改动能否迁移到新任务、新仓库、新模型？
8. 论文、厂商工程报告、公开源码和真实 trace 分别能支持多强的 claim？
9. 当前陈述属于 mechanism、contract、trace、eval 还是 inference，是否发生了跨级跳跃？
10. 未公开 backend 是否被明确留作 unknown，而不是用客户端代码或 UI 行为填空？

12. Kimi 作为 glass-box sample：服务 JD 解剖，不证明 frontier

本节只做两件事：把截图 JD 翻译为稳定的系统所有权；再用 Kimi Code 的公开快照验证这些对象确实能落到具体 service、scope 和 wire path。它 不 以 Kimi 公开源码多少判断产品领先程度，也不假设公开 agent-core-v2 等同内部生产系统。

能力前沿的校准继续来自第 11 节的两轴证据：Codex/Claude Code 提供更强的真实产品 contract、长任务与组织运行信号；Pi 提供 minimal harness 和可扩展协议的高可验证样本；Kimi 提供与目标岗位最接近的 glass-box code anatomy。四者承担不同研究角色。

12.1 JD 的中心不是“写 Agent”，而是拥有闭环边界

截图中的关键句是：让模型在真实代码仓库、真实工具链和真实开发流程中完成任务。按本文本体翻译：

真实代码仓库   = partially observable, concurrent environment
真实工具链     = capability + effect + receipt contracts
真实开发流程   = goal/constraint/authority/workflow integration
完成任务       = success criteria + independent evidence
模型之外系统   = harness + runtime + state + verification + trust

因此岗位不是普通 LLM application engineer，而是同时靠近 Agent Runtime / Harness、Developer Tools、Distributed Systems、Observability / Evaluation 的系统岗位。

12.2 JD 各条与基础本体的映射

12.3 Kimi Code 公开架构只是本文本体的一个具体落点

截至核验快照 29c9e2ab，公开 agent-core-v2 guide 明确存在四级生命周期：App / Workspace / Session / Agent。Workspace scope 拥有共享的 skills、agent profiles、instructions、MCP、filesystem watch、process、Git、tool policy、trust；Session 和 Agent 向下消费这些能力官方 agent-core-v2 guide。该 guide 自身仍将 v2 描述为 work-in-progress port，因此下述内容只属于 mechanism claim：公开快照怎样划分所有权。它不是对 Kimi 内部生产拓扑、SLA、最终架构或 capability frontier 的推断。作为 glass box，它说明：

• scope 不是 DI 装饰：它定义资源共享、身份、刷新、销毁和失败半径；
• workspace 不是 cwd 字符串：它是 trust、MCP、fs、process、Git 与 policy 的共同生命周期；
• session 不是 context window：它拥有跨 turn 持久化语义；
• agent 不是全局 singleton：subagent 需要自己的 identity、state 与 telemetry ambient context。

同一 guide 还暴露出三项高价值设计：

1. Persistence 按访问模式抽象：append log、atomic document、blob、domain query 分开；业务域不自行写文件或 SQL；
2. Conversation time 与 world time 分离：undo 只回退受 checkpoint 管理的会话状态，turn counters、task registries、revision 等 world-time state 不随 UI undo 回退；
3. Telemetry schema 是兼容性 contract：事件名和字段是 dashboard 消费的 wire data，重命名视为 breaking change。

它们分别对应本文的 state ownership、取消/回滚边界和 evidence contract。

12.4 用本文框架读 Kimi 公开源码，而不是从源码猜产品能力

不要问“这段代码做了什么”，先问它拥有哪一个状态转移：

读完每条路径，都要写一个“双结论”：

Verified mechanism : 在 29c9e2ab 中，owner X 通过 interface Y 维持 invariant Z。
Unresolved frontier: 没有 task distribution / model / budget / verifier / production trace，
                     因而不能判断它在线上比 Codex、Claude Code 或 Pi 更可靠。

这能避免两种同样浅的回答：看到开源实现就宣布领先；或因为未知线上能力而否认公开机制的学习价值。

12.5 面试中的一条主线

回答任何架构题都可以沿同一顺序：

1. 先定义 goal / success criteria / hard constraints
2. 列出 world、control、belief、context、presentation 五类状态
3. 标出概率决策与确定性 admission 的边界
4. 为每个 effect 定义 receipt、unknown、reconciliation、idempotency
5. 指定 durable journal、reducer、scope 与 crash recovery
6. 指定 verifier、evidence freshness 与 completion gate
7. 指定 human steering、approval、cancel 与 residual risk
8. 用 trace/metrics/eval 证明系统改进，而不是只画 happy path

这条主线比背框架名更能展示 Coding Agent 研发工程师的系统拥有能力。遇到竞品比较时，再追加：先标 claim 类型和证据轴，再比较固定联合配置下的 capability vector，最后列出 unknown backend。

13. 架构审查清单：用来判断任何新 Agent 产品

13.1 目标与边界

• intent 是否被编译成 goal、criteria、constraints，还是直接塞进 prompt？
• 哪些歧义允许模型推断，哪些必须问人？
• 谁能改变 scope、budget、permission、deployment target？
• hard constraint 是否可能在 fallback、compaction 或 subagent handoff 中丢失？

13.2 决策与执行

• model proposal 与 admitted action 是否有结构化分界？
• tool contract 是否表达 effect、idempotency、timeout、partial result、artifact？
• 并发由依赖/冲突模型驱动，还是“多调用就并行”？
• 未知 effect 怎样 reconciliation？

13.3 状态与恢复

• session、task、turn、step、effect 的 identity 是否稳定？
• journal、trace、transcript、telemetry、memory 是否分离？
• reducer 是否确定，schema/migration/repair 是否可测试？
• crash 后恢复的是状态还是重放动作？

13.4 完成与证据

• final answer 与 task success 是否分离？
• evidence 是否绑定当前 artifact/environment revision？
• verifier 不可用、覆盖不足或结论冲突时怎样表达 unknown？
• 真实用户的主观偏好怎样进入最后确认，而不伪装成自动 oracle？

13.5 学习与治理

• 能否定位 first bad transition？
• model/harness/environment/budget/verifier 是否完整指纹化？
• 新改动是否有 ablation、regression、shadow/canary 和 rollback？
• 线上 trace 进入 memory/eval/training 前怎样脱敏、去污染和校验？

14. 二十组层层追问与专家答题骨架

这些不是背诵答案。每组都要求从定义进入机制，再进入失败、证据和 trade-off。高质量回答的共同结构是：先定对象和所有者，再画状态转移，随后给不变量与失败语义，最后给可观测证据和适用边界。

14.1 到底什么是 Agent？

主问：请给出一个不依赖具体框架的 Agent 定义。

追问链：

1. 会 function calling 就算 Agent 吗？
2. 如果只有一次 tool call，没有循环呢？
3. 固定 workflow 中有 LLM 节点，算不算？
4. 模型没有长期 memory，还能算 Agent 吗？
5. “自主性”如何量化？

专家答题骨架：

• 定义为 goal-conditioned、partially observable、feedback-adaptive、bounded action loop；
• 给出 goal/policy/state/action/feedback/boundary 六要素；
• 区分完整 Agent 与局部 agentic inference；
• 说明 persistence 是长任务可靠性的要求，不是最小定义必要条件；
• 用 decision scope、action surface、horizon、authority、oversight distance 描述 autonomy 向量；
• 收口到 Coding Agent：外部 artifact 和 verifier 才定义输出。

危险回答：“Agent 就是 LLM + tools + memory + planning。”这是组件清单，不是定义，也没有说明闭环和边界。

14.2 Workflow 和 Agent 的本质区别是什么？

主问：两者都能多步执行，差异在哪里？

追问链：

1. workflow 可以有条件分支，为什么不算 Agent？
2. Agent 也可以先生成 plan，是否又变成 workflow？
3. 什么时候应该把 Agent 降级成 workflow？
4. 两者怎样组合最可靠？

专家答题骨架：

• 核心维度是 control-flow ownership：预定义 topology vs 模型根据新观察选择路径；
• 固定分支数量多仍是 workflow；模型生成 plan 仍只是可修订假设；
• 当路径可枚举、规则稳定、高风险或需要强审计时用 workflow；
• 给出 agent-in-workflow、workflow-as-tool、probabilistic planning + deterministic execution 三种 hybrid；
• 指出命名不是价值排序，能确定性解决就不应人为引入方差。

14.3 Copilot 和 Coding Agent 的边界在哪里？

主问：都是辅助写代码，为什么不是同一种产品？

追问链：

1. IDE 中自动应用 patch 的 copilot 是否已经是 Agent？
2. 用户每次都批准 tool call，还是 Agent 吗？
3. plan mode 是降低 autonomy 还是提高 trust？

专家答题骨架：

• 以 task-loop ownership 定义：copilot 由人选下一步、执行验证、决定完成；Agent 在授权段内自选路径和停止时机；
• 自动应用一次 patch 只是 action surface 增加，不必然取得 task loop；
• 每步审批不消除模型的路径选择，但缩短 authority horizon；
• plan mode 把 oversight 从单 action 提升到 strategy level，可能同时减少摩擦、提升有效控制；
• 说明 autonomy 与 human control 不是单轴零和。

14.4 Harness 与 runtime 为什么必须分开？

主问：如果 loop、tools、state 都在一个进程里，不是更简单吗？

追问链：

1. 你如何给 harness 和 runtime 划边界？
2. 更换模型时哪些应变化？
3. sandbox 死亡时谁恢复？
4. harness 崩溃后怎样继续？

专家答题骨架：

• 先声明 harness 行业存在宽/窄义，再给工作定义；
• harness 拥有模型行为假设、context/tool presentation、loop policy；runtime 拥有 episode lifecycle、durability、resources、leases、crash recovery；
• session/event log 外置，stateless harness 可 wake；sandbox 是独立 environment handle，可重建；
• pending effect 不能靠新 harness 猜，必须由 journal + reconciliation 恢复；
• 用 Anthropic Managed Agents 作证据，但不把其延迟数字普遍化。

14.5 请形式化一个 Agent step

主问：不要画 while true，给出状态和转移。

追问链：

1. world state 与 context 有何不同？
2. tool output 为什么不是 world state？
3. policy gate 放在哪里？
4. verifier 何时运行？

专家答题骨架：

• 写出 c=K(G,C,X,M,...)、u~π(c)、d=P(u,...)、W'=T(W,a)、o=Ω(W',receipt)、X'=δ(X,event)、v=V(criteria,evidence)；
• 说明 model proposal、admission、effect、observation、verification 的所有者不同；
• context 是 belief/control/history 的有限投影，不是真实世界；
• verifier 可在中间里程碑和 candidate completion 时运行；
• 最后给 safety/liveness 各一个不变量。

14.6 为什么 Agent 是部分可观测系统？

主问：代码仓库都在本地，为什么还叫 partial observation？

追问链：

1. 全盘读取仓库不就完全可观测了吗？
2. 1M context 能解决吗？
3. 怎样表示不确定性？
4. 哪些 observation 不可信？

专家答题骨架：

• 世界包含动态进程、依赖、远端状态、用户意图、未执行路径和并发修改，不可能一次完整观察；
• 可读不等于被注意，长 context 仍有选择、位置、成本、staleness 和 rot；
• belief item 要带 source、timestamp/revision、confidence、trust domain、coverage；
• repo/web/tool output 都可能携带低 authority 指令；
• 用 targeted observation + hypothesis test + evidence freshness 管理，而不是声称消除不确定性。

14.7 三个闭环分别解决什么问题？

主问：为什么 step loop 不够？

追问链：

1. 模型停止 tool calls 不就是完成吗？
2. task loop 与 verifier 怎么互动？
3. 线上 retry 成功了，还需要 learning loop 吗？
4. 三个循环各自的 owner 是谁？

专家答题骨架：

• step loop 保证局部 observe–act feedback；task loop 维护目标、预算和完成；learning loop 使系统从群体失败演进；
• 停止生成只表示 policy termination，不是 success；
• runtime recovery 能救单次，learning loop 负责系统性减少 cohort；
• 分别归属 loop/executor、task controller/verifier、eval/release system；
• 强调不能用外环实时替代内环，也不能用 retry 掩盖外环问题。

14.8 五种时间尺度怎样影响架构？

主问：为什么不能把所有状态都放 session object？

追问链：

1. request retry counter 属于哪一层？
2. 用户 steering 怎样跨 turn 生效？
3. session resume 应恢复什么？
4. 产品 rollout 如何与单次 trace 关联？

专家答题骨架：

• 列 token/request、step/effect、turn/task、session/long-run、product iteration；
• 每层给 state、owner、ID、persistence 和 consistency；
• 短时 transient state 不写入长期 memory，长期 constraints 不依赖 prompt 尾部保活；
• release/config fingerprint 进入每条 episode；
• 指出跨尺度污染是 messages[] 单体设计的核心债务。

14.9 “任务完成”如何定义？

主问：Agent 说 tests passed，能结束吗？

追问链：

1. 测试由 Agent 自己写，可信吗？
2. 用户要求是审美判断，怎样自动 verify？
3. verifier 挂了怎么办？
4. 测试结果来自修改前怎么办？

专家答题骨架：

• 完成是 criteria 对 fresh evidence 的覆盖，且无 constraint violation 与 unknown effect；
• 区分 execution receipt、semantic verifier、human preference judgment；
• Agent 生成测试可作为 evidence，但需现有回归、独立检查、mutation/coverage 或人工审查校准；
• 主观 criterion 返回需要人确认，不强造 oracle；
• verifier unavailable 返回 unknown/block，不让 model 自评 fallback；
• evidence 绑定 tree hash/environment/config/time。

14.10 Tool call、effect、receipt 为什么要拆开？

主问：工具返回 success: true 不够吗？

追问链：

1. HTTP timeout 后资源可能已创建，怎么办？
2. shell 被取消后呢？
3. 文件 edit 如何幂等？
4. read-only 工具也需要 receipt 吗？

专家答题骨架：

• intent 是愿望，action 是执行请求，effect 是世界变化，receipt 是关于变化的证据；
• 对 unknown effect 通过 idempotency key、query-by-operation-ID、read-after-write、process reconciliation 核对；
• shell 需处理 process tree/kill acknowledgement/background；
• patch 可绑定 base hash，重复应用返回 already-applied/conflict；
• 读工具仍需 source revision、truncation、freshness，防止把不完整 observation 当事实。

14.11 Cancel、timeout、retry、rollback 各是什么？

主问：用户按下停止后系统应保证什么？

追问链：

1. 能保证没有副作用吗？
2. timeout 是否等于 cancel？
3. 什么时候可以自动 retry？
4. rollback 失败怎样表达？

专家答题骨架：

• cancel 是撤销继续推进的意图并传播 cancellation，不承诺回滚已发生 effect；
• timeout 是 observer 未在期限内获得结果，effect 可能 unknown；
• retry 必须满足 transient + no-effect/known-idempotent + budget；
• rollback 是显式 compensation workflow，可能 partial/failed；
• 用户看到 committed/unknown/compensated/residual effects，而不是一个绿色“已取消”。

14.12 Journal、trace、transcript、telemetry、memory 有何区别？

主问：为什么不能全部存 JSONL？

追问链：

1. JSONL 也能给 UI 读，为什么要 transcript？
2. trace 能否恢复 session？
3. telemetry 为什么不能包含 prompt？
4. raw history 为什么不是 memory？

专家答题骨架：

• 存储格式相同不等于语义相同；按问题、保留、隐私、完整性和消费者区分；
• journal 是 durable facts，transcript 是用户投影，trace 是因果诊断，telemetry 是群体聚合，memory 是治理后的跨 scope 知识；
• sampled trace 不能做 recovery truth；
• telemetry 避免内容/高基数/secret，prompt 需更强治理；
• raw history 含错误、陈旧和无关细节，不能直接变长期策略。

14.13 为什么状态必须有唯一 owner？

主问：多个组件各缓存一份不是更快吗？

追问链：

1. UI 与 backend 状态不一致怎么办？
2. model context 中的 plan 与 durable plan 不一致呢？
3. cache 可以写吗？
4. 多设备 session 如何解决？

专家答题骨架：

• 区分 authoritative source 与派生 cache/projection；允许多读副本，不允许多主语义；
• 所有改变经过 domain event/version，UI/context 带 revision；
• stale projection 显式丢弃或增量追平；
• plan 由 durable task state 拥有，context 只是快照；
• 多设备需要 session sequence/optimistic concurrency/steering admission，而不是 last-write-wins 聊天数组。

14.14 如何设计一个 crash-safe 的长任务 Agent？

主问：进程在 tool call 中间崩溃，怎样恢复？

追问链：

1. journal 最后一条是 effect.started 呢？
2. reducer schema 升级了呢？
3. worker 恢复时旧 worker 又活了呢？
4. context 不够装全部历史呢？

专家答题骨架：

• append intent/admission/start before effect，receipt after；
• crash 后 replay deterministic events，pending effect 进入 reconciliation；
• lease/fencing token 防 stale worker 双写；
• schema version + migration + corrupt record policy + repair audit；
• durable session 与 model context 分开，由 context compiler 选择/压缩/取 artifact；
• 恢复验收包括 state equivalence 和 no-duplicate-effect，不只是“能继续说话”。

14.15 如何用 Kimi 的 App / Workspace / Session / Agent 做 glass-box 解剖？

主问：为什么不使用一个全局 service container？

追问链：

1. Git、process、MCP 应放哪层？
2. subagent 共享什么、不共享什么？
3. workspace trust 为什么不属于 session？
4. scope 选错有什么具体失败？

专家答题骨架：

• scope 定义 ownership、sharing、refresh、disposal、identity 和 failure radius；
• App 放跨 workspace registry/基础设施；Workspace 放 fs/Git/process/MCP/trust 资源；Session 放交互与任务容器；Agent 放个体 loop/context/identity；
• subagent 可共享 workspace capabilities，但拥有独立 task/context/telemetry principal；
• workspace trust 绑定资源根和项目配置，不应每 session 重复或漂移；
• 选太高导致跨任务污染与权限泄露，选太低导致重复初始化、状态分叉与资源泄漏。
• 收尾必须限定 claim：这是 29c9e2ab 的 ownership mechanism，不代表 Kimi 私有生产拓扑，更不能由 scope 设计直接推出 capability frontier。

14.16 如何定位 model failure 还是 harness failure？

主问：同一任务失败，应该训模型还是改系统？

追问链：

1. 模型没找到关键文件算谁的？
2. 模型看到了证据仍选错呢？
3. 更强模型成功是否证明是 model failure？
4. 如何做 ablation？

专家答题骨架：

• 先找 first bad transition，而不是按最终组件归罪；
• 固定 task/environment/budget/verifier，交叉 model × harness；
• 检索没暴露可用动作/上下文是 harness acquisition；证据充分仍稳定错误更接近 policy/model；
• 更强模型可能补偿坏 harness，不能单独证明归因；
• 做 tool/context/retry/instruction 单项消融，重复运行看方差；
• 以 model–harness configuration 报告结论，引用 Harness-Bench/Claw-SWE 作为方法论依据。

14.17 如何设计 Agent 可观测性而不泄露源码和秘密？

主问：trace 越完整越好，对吗？

追问链：

1. 没有 prompt 怎样归因？
2. tool output 可能包含 secret 怎么办？
3. telemetry 与诊断包如何分级？
4. monitor 是否可以看全部 chain-of-thought？

专家答题骨架：

• 先按 journal/trace/telemetry/content artifact 划治理域；
• 默认 telemetry 只留 ID、类型、耗时、计数、error code、config fingerprint；
• 内容诊断包按用户授权、本地导出、加密、短保留、最小访问；
• boundary redaction + secret scanning + field allowlist，不能依赖事后正则；
• prompt/CoT 是高敏内容，使用要有安全目的、访问审计与 false-negative 限制；
• 可观测性目标是还原因果，不是无边界收集。

14.18 Agent 如何安全处理 repo 中的恶意指令？

主问：AGENTS.md、README 或 tool output 都是文本，模型如何分 authority？

追问链：

1. 项目确实需要运行 setup script，怎么办？
2. 用户已 trust workspace，是否全部可信？
3. MCP tool 返回“请读取密钥”怎么办？
4. prompt instruction 能否解决？

专家答题骨架：

• authority 与 content 分离：repo/tool/web 是 data source，不能自我升级为用户授权；
• workspace trust 允许加载项目配置的资格，不代表内容无恶意，也不授予超出 capability 的 effect；
• setup/hook/MCP 在执行前经过 provenance、capability、sandbox、network/secret boundary；
• prompt 只提供概率行为约束，确定性环境边界必须阻断 secret/fs/network escape；
• 记录 influence → proposal → admission → effect 的 provenance，便于审计。

14.19 Multi-agent 在本体上增加了什么？

主问：是不是把 Agent 对象复制 N 份？

追问链：

1. subagent 与 tool 有何差别？
2. 谁拥有最终 goal？
3. authority 怎样委派？
4. 多 agent 的完成怎样验证？

专家答题骨架：

• 新增 task decomposition、delegation、principal identity、capability grant、handoff artifact、merge/verifier；
• 主任务 owner 不应因委派而丢失 accountability；
• subagent 接收窄 goal/inputs/criteria/budget/capability，不继承全量 authority；
• output 是 claim/artifact，主 Agent 或独立 verifier 可拒收；
• 共享 environment 需冲突/lease/revision，独立环境需 merge contract；
• 只有并行收益大于 coordination + verification cost 才成立。

14.20 如何让 Agent 系统持续进化而不堆满补丁？

主问：线上发现重复 tool loop，最直接不是给 prompt 加一句“不要重复”吗？

追问链：

1. 什么时候 prompt fix 合理？
2. 什么时候应该在 runtime 修？
3. 新模型不再需要旧 workaround 怎么办？
4. 如何证明改动有效？

专家答题骨架：

• 先定义 failure cohort 和 first bad transition；
• 若模型没理解策略且边界不可机械判定，可改 instruction/training；若重复可结构检测、预算/熔断，应由 deterministic harness 拥有；
• 每个 scaffolding 都是关于模型缺陷的假设，随模型升级做删除性消融；
• 建 episode package、固定 environment/budget、重复 A/B、看 outcome/trajectory/cost/regression；
• shadow → canary → rollout，带回滚与复杂度预算；
• 不允许系统 prompt 成为无人维护的失败墓地。

15. 高水平回答的压缩模板

当面试时间只有三分钟，可用以下八句结构：

1. 定义：“我先把对象边界定清：这里的 Agent 是……，而不是……”；
2. 状态：“我会分 world、control、belief、context、presentation 五类状态”；
3. 控制权：“模型提出 proposal，确定性 policy 决定 admission”；
4. 作用：“intent、effect、receipt 分开，unknown effect 先 reconciliation”；
5. 持久化：“journal 是事实源，reducer 恢复状态，trace 负责因果诊断”；
6. 完成：“success criteria 由 fresh evidence 和 verifier 决定，不由 final message 决定”；
7. 失败：“按 first bad transition 归因，并给 retry/cancel/recovery 的语义”；
8. 证明：“最后用 model × harness ablation、轨迹指标和分阶段 rollout 验证”。

这不是固定话术；它是一种防止回答滑回“模型—prompt—工具”表层的思考顺序。

16. 一手资料索引与证据等级

16.1 Frontier 产品 contract 与真实实践信号

Codex

• OpenAI Codex 官方仓库快照 bb5054fe
• OpenAI: Unrolling the Codex agent loop
• OpenAI: Running Codex safely at OpenAI（controls、boundaries、identity、network 与 telemetry；2026-05-08）
• OpenAI: How agents are transforming work（真实使用和模型估计 horizon；2026-06-25，不是 correctness eval）
• OpenAI: Harness engineering
• OpenAI: Monitoring internal coding agents for misalignment
• OpenAI: A practical guide to building agents（持续更新的官方 guide；页面未展示稳定发布日期，核验于 2026-08-03）

Claude Code

• Claude Code: How Claude Code works（loop、环境、session、context、checkpoint；滚动文档核验于 2026-08-03）
• Claude Agent SDK: How the agent loop works
• Claude Code permissions 与 sandboxing
• Anthropic: Trustworthy agents in practice
• Anthropic: Measuring AI agent autonomy in practice
• Anthropic: Scaling Managed Agents
• Anthropic: Effective context engineering for AI agents

Pi

• Pi 官方仓库快照 c6eb6281
• Pi latest documentation（minimal terminal coding harness；滚动文档核验于 2026-08-03）
• Pi RPC Mode（严格 JSONL command / response / event contract）
• Pi extensions（tool、event interception、context、compaction、session persistence）
• Pi compaction and branch summarization

跨产品治理参照：NIST Software and AI Agent Identity and Authorization concept paper。它是 concept paper，不是标准。

16.2 Kimi / Moonshot glass-box 事实源

• Kimi Code 官方仓库快照 29c9e2ab
• agent-core-v2 设计与 scope / persistence / telemetry 约束
• Turn / Step loop
• Tool executor
• Wire journal / replay
• Context memory
• Permission gate
• Kimi K3 官方仓库与技术报告快照 7c5be959

这些路径支持 Kimi 公开实现的 mechanism claim。它们不支持“开源所以领先”，也不暴露私有生产 backend、产品 trace 或完整 outcome eval。

16.3 2026 原始研究论文

• Harness-Bench: Measuring Harness Effects across Models, v1
• Claw-SWE-Bench: Evaluating OpenClaw-style Agent Harnesses, v1
• AI Harness Engineering: A Runtime Substrate, v1
• Agentic Harness Engineering: Observability-Driven Automatic Evolution, v4
• CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents, v1

16.4 作为定义史而保留的早期一手来源

• Anthropic: Building effective agents（2024；workflow 与 agent 的经典工程区分）
• ReAct: Synergizing Reasoning and Acting in Language Models（2022；reasoning–acting–observation 交错范式）

16.5 证据不是单一等级，而是两张独立量表

Provenance / verifiability 量表评“能否复核这个 claim”：

Capability / frontier 量表评“结果证据有多接近可比较能力”：

V3/F0 完全可能：源码极透明，但只有 feature contract。V2/F1 也可能代表强 frontier signal：私有系统仅披露真实长任务与组织使用，却没有可复现结果。两者不可混成一个字母等级，更不能按主观权重相加得“总分”。

形成跨产品 capability claim 的最低证据包应包含：版本化 product contract、完整联合配置、任务分布、环境镜像、预算、原始 outcome、verifier、重复次数/方差、失败分母、延迟与单位成功成本。缺哪一项，就把对应结论降格为 contract、trace 或 inference，并列出 unknown。

本文的核心本体和不变量从系统工程第一原则推导；2025–2026 资料用于验证哪些问题已经在真实 Agent 系统中成为主要控制边界。不要把任何一篇论文、一个 benchmark、一个公开仓库或一家厂商的产品实践升格为唯一架构或绝对 frontier。

17. 最终自检：真正“讲透”本部分的标准

如果你能不依赖框架名，独立完成以下推导，才算掌握本部分：

• 从用户意图写出 goal、success criteria、constraints、scope；
• 形式化 world/control/belief/context/presentation state；
• 画出 proposal → admission → action → effect → receipt → observation；
• 解释 Agent、workflow、copilot、automation、harness、runtime、environment 的所有权差异；
• 画出 step/task/learning 三环及五种时间尺度；
• 为一个长任务定义 crash、cancel、timeout、unknown effect、reconciliation；
• 指定 journal、trace、transcript、telemetry、memory 的不同真相职责；
• 用 fresh evidence 和 verifier 定义完成，而不是引用模型自述；
• 从失败结果向前定位 first bad transition；
• 将 Kimi 的 App/Workspace/Session/Agent scope 映射为生命周期和资源所有权，同时明确它只是公开快照的 glass-box mechanism；
• 读一项新 Agent 技术时，能说明它究竟改变 model、harness、runtime、environment、verifier 还是 authority plane；
• 对所有“性能提升”追问 task、environment、budget、harness、verifier、方差和外推边界。
• 将 provenance/verifiability 与 capability/frontier 分轴报告，并把每条结论标为 mechanism、contract、trace、eval 或 inference；
• 比较 Codex、Claude Code、Pi、Kimi 时，不用公开程度代替能力，不用使用时长代替正确性，也不为未知私有 backend 补图。

最后只保留一句总原则：

Agent Engineering 的研究对象不是会生成动作的模型，而是一个在不完整信息与真实副作用下，仍能维持目标、边界、状态、证据和责任连续性的执行系统。