夜雨聆风总览
1. 介绍
AI Coding 已经从“根据注释补几行代码”发展为覆盖需求澄清、规格设计、代码实现、测试验证、代码评审和交付治理的工程体系。大量新名词同时出现，但它们并不处在同一层：
Vibe Coding、Agentic Coding 描述开发范式。
Spec-Driven Development 描述需求和实现之间的组织方法。
OpenSpec、Spec Kit、BMAD、GSD Core 是具体框架或工作流。
Context Engineering、Harness Engineering 描述 Agent 的工程基础。
MCP、ACP、A2A、AG-UI 描述不同对象之间的互操作协议。
Skills、Hooks、Subagents、ACI 描述 Agent 的扩展和执行机制。
Verifier、Evals、TDD、安全沙箱描述结果验证和风险控制。
本文按这些概念解决的问题进行分层，后续也按照此进行展开，重点说明相互关系和适用场景。
2. AI Coding 的演进
AI 编程的演进不宜被概括为单一的线性阶段模型。代码补全、Chat 和 Agent 是交互与能力形态；Vibe Coding 是使用风格；Agentic Engineering 是工程纪律；Autonomous Coding 描述自主程度。它们位于不同维度，可以同时存在。
| 维度 | 主要变化或选择 | 作用 |
| --- | --- | --- |
| 交互与能力形态 | 代码补全 → 对话式编程 → 能调用工具的 Coding Agent | AI 以什么方式参与开发 |
| 自主与授权程度 | 只给建议 → 人监督下执行 → 后台或长时自主执行 | AI 可以独立行动到什么程度 |
| 工程方法 | Vibe、Spec-Driven、Verification-Driven、Harness Engineering | 团队怎样组织意图、实现、反馈与治理 |
| 人机责任 | 人逐行实施 → 人定义目标、边界、验收和风险，AI 执行更多机械工作 | 最终判断和责任由谁承担 |
3. 总体概念分层
AI Coding 可以分成九个相互配合的层次。一个完整的 Coding Agent 产品通常会同时覆盖其中多层，如下图：
4. 开发范式
4.1. AI-Assisted Development 与 Local Assistive Coding
广义的 AI-Assisted Development 指任何由 AI 辅助的软件开发，也可以包含 Agentic Coding。
为了进行能力的区分，文章用 Local Assistive Coding（局部辅助式开发）指补全代码、解释报错、生成测试或重构函数等局部工作；人掌握完整执行过程，AI 通常不会自行操作整个仓库。
4.2. Vibe Coding
Vibe Coding 强调通过自然语言和快速运行反馈推进开发。Andrej Karpathy 最初提出这个词时，语境还包括较少阅读 Diff、接受生成代码并把报错继续交给模型。它适合原型、个人工具和低风险实验，但“看起来能运行”不能代替需求、测试、安全和可维护性验证。
若开发者仍系统审查代码、验证设计并承担工程治理，更准确的名称通常是 AI-Assisted Development、Agentic Coding 或 Agentic Engineering。
4.3. Agentic Coding
Agentic Coding 指 AI 不只生成文本，还能够：
搜索和读取仓库；
编辑多个文件；
调用 Shell、浏览器、数据库或其他工具；
执行构建、测试和静态检查；
根据执行结果继续修复；
生成提交、变更说明或 Pull Request。
4.4. Agentic Engineering
Agentic Engineering 是面向 Coding Agent 的工程化开发方法，通过规格、仓库约束、自动化验证、权限控制、可观测性、任务状态和团队治理，构建稳定、可控、可验证的 Agent 开发与交付环境。
4.5. Autonomous Coding
Autonomous Coding 是 Agent 在较少人工干预下持续完成开发任务的编程方式。其自主程度沿着从人工主导到高度自主的连续区间变化，并由任务范围、人工介入频率和执行权限共同决定。明确目标、停止条件、验证反馈和风险边界共同构成自主执行的基本保障。
5.意图与规格
5.1 Prompt Engineering
Prompt Engineering 是设计和表达指令的方法，涵盖目标、约束、输出格式、角色和示例。Prompt 既可以服务于单次请求，也可以作为系统提示、工具描述或版本化模板长期维护。Prompt Engineering 聚焦指令的表达方式，Context Engineering 则覆盖推理过程中全部信息的选择、组织和更新。
5.2 Intent-Driven Development
Intent-Driven Development 把人的意图视为核心输入。它强调先明确要解决的问题、成功标准和不可破坏的约束，再选择实现方式。规格、测试和代码都是意图的不同表达。
5.3 Spec-Driven Development
规格驱动开发（Spec-Driven Development，SDD）把规格从参考资料提升为核心工程资产。常见流程是：
需求意图 → 可评审规格 → 技术设计 → 实施任务 → 代码实现 → 一致性验证
SDD 中常见的配套概念如下：
ADDED/MODIFIED/REMOVED 是 OpenSpec 的具体形式 | |
下面的图展示 SDD 的业务闭环，不表示某个框架的固定命令。
5.4 OpenSpec
OpenSpec 是面向 AI Coding Assistant 的轻量 SDD 框架。它把版本化的规格和变更提案作为人、Agent 与代码之间可持续维护的约定，尤其关注已有代码库。
OpenSpec 的核心模型包括：
openspec/specs/ 保存系统当前应该具备的行为。
openspec/changes/ 为每次变更保存 Proposal、Delta Spec、Design 和 Tasks。
Delta Spec 使用 ADDED、MODIFIED、REMOVED 表达行为变化。
实现完成后归档变更，并把 Delta 合并进现行规格。
规格和代码一起进入 Git、代码评审和团队协作流程。
openspec/
├── specs/
│ └── navigation-task/
│ └── spec.md
└── changes/
└── add-task-recovery/
├── proposal.md
├── design.md
├── tasks.md
└── specs/
└── navigation-task/
└── spec.md
OpenSpec 与普通 Plan Mode 具有不同的状态范围：Plan Mode 通常服务于一次会话，OpenSpec 生成的规格和任务可以跨会话、跨 Agent、跨成员长期保存。OpenSpec 负责管理意图和变更，MCP 负责连接外部工具。
5.5 GitHub Spec Kit
GitHub Spec Kit 是更完整、可扩展的 SDD Harness。其核心链路是：
Constitution → Specify → Plan → Tasks → Implement → Converge
其中 Constitution 用于保存项目级不可轻易破坏的原则；Clarify、Checklist 和 Analyze 是按项目需要插入的质量步骤，具体命令链可以随项目调整。Spec Kit 同时适用于 Greenfield、探索性开发和 Brownfield。
5.6 Kiro Specs
Kiro Specs 把规格工作流集成到 IDE、Web 和 CLI 环境中，支持 Feature、Bugfix 与 Quick Spec。Feature Spec 可以从 Requirements 或 Design 开始，再补齐另一侧并形成 Tasks。主要产物包括：
requirements.md：用户故事、需求和验收条件；
bugfix.md：Bugfix Spec 的问题、预期行为和复现信息；
design.md：技术架构、接口和设计决策；
tasks.md：可跟踪、可并行执行的任务。
Kiro 还使用 EARS 等结构化需求表达方式。EARS 通过固定句式减少需求中的触发条件、状态条件和异常条件歧义。
6. 上下文与知识
6.1 Context Window
Context Window 是模型当前能够直接处理的信息范围。它包含系统规则、用户请求、对话历史、文件内容、工具结果和 Agent 生成的中间信息。
更大的上下文窗口仍需按照任务相关性装配内容。无关信息会稀释重点，并增加冲突和错误引用。
6.2 Context Engineering
Context Engineering 研究如何在正确时间向 Agent 提供正确的信息。它通常包括：
按需读取任务相关文件，并控制仓库内容的加载范围；
保留文件路径、符号名和任务编号等轻量索引；
把长期规则、当前任务和历史经验分层；
在上下文接近上限时进行压缩或交接；
让执行结果成为下一步判断的上下文；
避免过期文档、无关日志和重复内容占用注意力。
这类按需获取方式也被称为 Just-in-Time Context。
6.3 Context Rot
Context Rot 是随着输入上下文增长，模型对相关信息的定位、保持和利用能力出现不稳定或下降的长上下文退化现象。在 Coding Agent 中，它常表现为重复搜索、遗漏验收条件、修改范围扩大和前后决策不一致；任务拆分、检索质量和状态管理也会影响这些表现，因此需要结合执行证据判断具体原因。
工程上通常通过任务拆分、上下文压缩、Fresh Context、结构化任务状态以及将关键知识写回仓库来缓解 Context Rot。
6.4 Memory、Compaction 与 Checkpoint
Memory、Compaction 与 Checkpoint 是支持 Agent 长任务连续性的三类机制，分别负责知识复用、上下文压缩和执行恢复：
Memory 是 Agent 跨会话保存和检索知识的机制。它可以使用外部可检索记忆（Persistent Memory）保存项目经验、用户偏好和已验证结论，也可以通过 Spec、ADR、Task、Progress 等仓库工件保存团队可审查状态。
Compaction 是将逐渐增长的 Working Context 压缩为目标、关键决策、执行证据、当前状态和剩余工作的过程。压缩结果既可以留在当前会话中继续使用，也可以作为 Handoff 交给新会话、新 Agent 或新进程。
Checkpoint 是对可恢复执行位置、已完成步骤、外部副作用和验证结果的持久化快照，用于在进程或会话中断后安全恢复执行。
三者作用于不同阶段：Memory 负责跨会话积累知识，Compaction 负责控制当前上下文规模并传递任务主线，Checkpoint 负责从持久状态恢复执行。可长期复用的知识应具备可检索、可追溯、可更新和失效识别能力。
6.5 Repository Instructions
Repository Instructions 是与代码一起保存在仓库并进行版本管理的项目级指令，用于向 Coding Agent 持续提供项目规则、执行方法和修改边界。常见载体包括：
AGENTS.md
CLAUDE.md
GEMINI.md
.github/copilot-instructions.md
Cursor Rules
Kiro Steering
Repository Instructions 通常记录构建命令、测试入口、目录职责、编码规则、禁止修改范围和常见陷阱等长期有效信息。一次性功能需求由当前规格或任务工件承载，使长期规则与本次变更目标保持分离。
不同产品通过各自的文件名、目录作用域、继承和优先级规则决定 Repository Instructions 的加载范围与冲突处理顺序。每份仓库指令都应标明适用目录，并通过实际 Agent 运行验证规则是否按照预期生效。
6.6 Agent Skills
Agent Skill 是可发现、可复用的专业工作流包，用于把特定任务的适用条件、执行步骤、工具资源和验收方式封装成 Agent 可以按需加载的能力。典型结构包括：
SKILL.md：适用场景、步骤、限制和验收规则；
脚本：执行确定性操作；
参考资料：按需加载的领域知识；
模板和资源：统一输入与输出结构。
Agent Skills 面向可复用的任务类型，规定这类工作应按照什么流程完成并如何验收结果。Repository Instructions 面向具体代码仓库，规定 Agent 在该项目中长期遵守的规则和修改边界。两者共同为 Agent 提供专业工作方法和项目执行约束。
6.7 代码检索与结构化上下文
代码检索与结构化上下文是 Coding Agent 从代码库中定位相关信息、建立程序结构关系并形成任务所需上下文的机制。它由精确搜索、语法分析、符号关系、语义召回、仓库概览和运行证据共同构成。
这些技术组成从候选定位到结构分析再到运行验证的代码理解链路。文本搜索和语义检索负责召回候选内容，AST、LSP 与 Code Graph 负责分析结构关系，Repository Map 提供仓库概览，Runtime Evidence 负责验证静态判断。Agent 根据任务范围、相关性和信息时效组织检索结果，并形成当前任务的结构化上下文。
6.8 Instruction Hierarchy、Trust Boundary 与 Context Provenance
Instruction Hierarchy、Trust Boundary 与 Context Provenance 是 Agent 判断上下文能否作为指令、证据或背景信息的三类机制。它们共同描述信息的权限、可信范围和来源状态。
系统策略、用户授权和仓库规则属于不同层级的控制信息，源码、Issue、PR 评论、网页和工具输出属于不同可信程度的任务证据。语义相关性决定信息是否值得召回，Instruction Hierarchy、Trust Boundary、Provenance 和 Freshness 共同决定信息怎样进入推理和执行过程。
7. Agent 架构
Agent 架构是模型围绕目标持续获取上下文、选择动作、调用工具、接收反馈并判断任务状态的系统结构。一个完整的 Coding Agent 由模型、循环、运行系统、执行环境、状态、权限和验证机制共同组成。
Agent 的任务完成能力由各层共同决定。模型提供推理能力，Harness 和 Environment 提供行动条件，State 保持执行连续性，Policy 控制授权边界，Verifier 负责提供完成证据。
7.1 Workflow 与 Agent
Workflow 是由代码预先规定执行路径的自动化流程，Agent 是由模型根据当前观察动态选择下一步动作的执行系统。Workflow 适合固定、可预测和需要确定性门禁的步骤，Agent 适合搜索空间较大、路径难以预先穷举的任务。
实际 Coding 产品通常同时包含 Workflow 与 Agent。Workflow 固化构建、测试、审批和发布等稳定环节，Agent 负责需求理解、代码探索、方案选择和动态修复。
7.2 Agent Loop
Agent Loop 是 Coding Agent 在目标、动作和反馈之间持续迭代的基本运行循环。每一轮循环都会读取当前状态、选择下一步动作、执行工具调用、观察结果并更新后续判断。
理解目标 → 获取上下文 → 选择动作 → 调用工具 → 观察结果 → 更新计划 → 继续或停止
Agent Loop 通过完成条件结束循环，通过失败反馈触发修复，通过状态记录保持多轮执行的一致性。循环的可靠性取决于目标是否明确、工具反馈是否完整以及完成条件是否可以验证。
7.3 Harness Engineering
Harness Engineering 是围绕 Agent 构建运行、约束、反馈和恢复系统的工程方法。Harness 位于模型之外，把模型能力转化为能够在真实工程环境中持续工作的执行能力。
同一个模型在不同 Harness 中会表现出不同的工程稳定性。Harness Engineering 通过环境、工具、约束和反馈减少重复错误，并让 Agent 的执行过程具备可控性和可验证性。
7.4 Agent–Computer Interface
Agent–Computer Interface（ACI）是 Agent 感知和操作计算机环境的接口集合。它包含命令、参数、文件表示、诊断信息、测试结果和状态反馈，决定 Agent 能够看到什么、怎样行动以及怎样理解执行结果。
对 Agent 友好的 ACI 使用清晰的工具边界、稳定的参数结构、可定位的错误信息和适量的结果输出。搜索、编辑、诊断和测试接口共同影响 Agent 完成代码任务的效率与可靠性。
7.5 Tool Calling
Tool Calling 是模型提出结构化动作请求、Harness 执行动作并返回结果的交互机制。工具可以连接文件系统、终端、浏览器、数据库、代码托管平台和内部服务。
模型生成工具调用表示执行意图，Harness 完成调用并返回可验证结果表示动作已经发生。Browser Use 和 Computer Use 是 Tool Calling 在页面和桌面环境中的交互形式，适用于缺少稳定 API 的系统，并依赖更严格的状态识别、权限控制和结果验证。
7.6 Structured Output 与 Tool Contract
Structured Output 是使用 JSON Schema 等结构约束模型输出的机制。它保证字段名称、类型和嵌套关系符合预定结构，使 Harness 能够稳定解析模型结果。
Tool Contract 是工具调用双方共同遵守的执行契约。它描述鉴权方式、输入边界、副作用等级、幂等性、超时、重试条件、错误语义、审批条件和结果证据。Structured Output 负责结构正确性，Tool Contract 负责调用语义和执行边界。
7.7 Plan/Act 与 ReAct
Plan/Act 是把任务理解与实际执行分成不同阶段的控制模式。Plan 阶段形成目标、范围、方案和验证方法，Act 阶段按照计划修改环境并执行验证，Review 阶段检查结果与计划的一致性。
ReAct 是让推理、动作和观察交错进行的控制模式。它根据新出现的执行证据持续调整下一步动作。真实 Agent 系统会按照任务阶段组合 Plan/Act 与 ReAct，在稳定计划和动态修正之间切换。
7.8 Subagent
Subagent 是由主 Agent 委派、拥有独立任务上下文或执行范围的 Agent 调用。它用于代码探索、测试执行、安全检查、资料整理和独立代码评审等边界清晰的子任务。
Subagent 通过独立上下文减少主会话噪声，通过任务范围和验收条件限制工作边界。它与主 Agent 之间通过任务描述、状态、结果和证据完成交接，其文件系统、凭据、进程、权限和网络范围由 Harness 定义。
7.9 Multi-Agent Orchestration
Multi-Agent Orchestration 是组织多个 Agent 分工、依赖、并行执行和结果汇总的编排机制。它把一个复杂目标拆成可以独立推进的任务，并协调任务之间的顺序、所有权和共享状态。
多 Agent 系统通过编排成本换取并行能力。任务边界、独立验证条件和共享状态越清晰，多 Agent 越容易形成稳定收益。
7.10 Model Routing
Model Routing 是根据任务类型、复杂度、延迟、成本和风险选择模型的调度机制。它把不同模型分配到推理、搜索、格式化、简单修改和独立评审等不同工作上。
Model Routing 通过任务分类和结果验证形成模型选择闭环。高推理模型承担架构设计和疑难调试，低延迟模型承担搜索和机械修改，独立模型承担交叉评审，最终结果由统一的验证标准判断。
8. 工具、协议与互操作
工具、协议与互操作机制描述 Coding Agent 怎样连接编辑器、外部能力、其他 Agent 和用户界面。不同协议连接的对象不同，产品扩展点和工作流知识包也不属于同一类型。
8.1 MCP
Model Context Protocol（MCP）是 AI 应用连接外部上下文和工具能力的开放协议。MCP Host 管理一个或多个 Client，Client 与 MCP Server 建立会话，Server 对外提供 Resources、Prompts 和 Tools 等能力。
MCP 统一了外部能力的发现和调用方式。它负责连接工具与上下文，完整开发流程由上层 Agent 工作流组织，Server 信任、最小权限和 Prompt Injection 防护由安全治理体系负责。
8.2 ACP
Agent Client Protocol（ACP）是编辑器或 IDE Client 与 Coding Agent 之间的互操作协议。它通过能力协商复用会话、消息、文件操作、权限请求、终端和 MCP 等 Coding 交互能力。
ACP 连接的是代码编辑环境与 Coding Agent。它使 Agent 实现与编辑器界面解耦，并让不同 Agent 复用相近的 Coding UX。本文中的 ACP 专指 Agent Client Protocol，不表示 Agent 间通信或商业交易协议。
8.3 A2A
Agent2Agent Protocol（A2A）是独立 Agent 应用之间进行能力发现、消息交换、任务管理和结果交付的互操作协议。Agent Card 描述 Agent 能力，Task 表示任务生命周期，Message 和 Artifact 承载交互内容与任务产物。
A2A 面向跨团队、跨产品或跨供应商的 Agent 协作。单个产品内部的 Subagent 由 Harness 编排，Agent 使用的外部工具和上下文由 MCP 连接。
8.4 AG-UI
Agent User Interaction Protocol（AG-UI）是用户界面应用与 Agent 后端之间的双向事件协议。它覆盖流式消息、共享状态、用户中断、运行事件和前端工具调用。
AG-UI 面向通用 Agent 前端与后端的交互，ACP 面向代码编辑器与 Coding Agent 的交互。两者都处理交互状态，但它们服务的界面类型和协议对象不同。
8.5 Hooks
Hooks 是产品在 Agent 生命周期事件上提供的处理器扩展点。Hook 在预定事件发生时执行格式化、校验、阻断、记录或自动化动作。
命令型 Hook 在模型之外形成确定性门禁，Prompt 型和 Agent 型 Hook 会再次调用模型并产生概率性结果。事件名称、阻断语义和权限模型由具体产品定义。
9. 任务与自主执行
任务与自主执行机制描述 Coding Agent 怎样把目标转化为可推进的工作、怎样保存跨轮状态，以及怎样在较少人工干预下持续运行。任务拆分、依赖管理、执行恢复和停止条件共同构成长任务的控制结构。
9.1 Task Decomposition
Task Decomposition 是把大目标拆成边界明确、依赖清楚且可以独立验收的小任务的过程。每个任务包含输入、修改范围、依赖关系、验收条件和验证方式。
任务拆分按照业务边界、代码所有权和验证闭环组织工作。上下文容量控制单个任务的规模，依赖关系控制任务的执行顺序，验收条件定义任务的完成状态。
9.2 Task Graph
Task Graph 是使用节点和依赖边表示任务关系的结构化任务模型。节点保存任务内容与状态，依赖边表示先后关系、阻塞条件和并行可能性。
多 Agent 场景中的 Task Graph 还包含 Assignee、Atomic Claim 或 Lease 等所有权信息。这些字段让系统识别就绪任务、避免重复领取，并记录任务从创建到完成的状态变化。
9.3 Fresh Context
Fresh Context 是为任务建立新的或相互隔离的上下文窗口的执行方式。它可以通过新会话、新进程或 Fresh Subagent 实现，并通过规格、Git 历史、任务状态和进度工件传递跨上下文连续性。
Fresh Context 保留完成当前任务所需的项目状态，同时减少旧对话、重复结果和过期判断形成的历史噪声。它与 Compaction、Handoff 和 Persistent Task State 共同支持长任务推进。
9.4 Git Worktree Parallelism
Git Worktree Parallelism 是使用多个 Git Worktree 为不同任务或 Agent 提供独立工作目录、Index 和 HEAD 的并行开发方式。每个 Worktree 通常对应独立分支，并隔离文件修改与暂存状态。
Worktree 解决文件工作区冲突，不直接隔离端口、数据库、构建缓存和其他共享资源。文件所有权、资源分配和集成顺序共同处理语义冲突与环境冲突。
9.5 Ralph Loop
Ralph Loop 是持续把目标、外化状态和执行反馈重新交给 Coding Agent 的迭代执行技术。每轮执行都读取规格、任务状态、Git 变更和验证结果，再选择下一项工作并更新状态。
Ralph Loop 依靠可执行验收、构建、测试和静态检查形成反馈闭环。最大轮数、时间预算、成本预算、连续失败阈值和取消入口共同定义循环的停止边界。
9.6 Background Agent 与 Remote / Cloud Agent
Background Agent 是以异步方式运行任务的 Agent，Remote / Cloud Agent 是在远程或云端环境中运行任务的 Agent。Background 描述调度方式，Remote / Cloud 描述执行环境位置，二者可以同时存在。
这类 Agent 通过摘要、Diff、分支、Commit 或 Pull Request 交付结果。持久状态、取消机制、执行日志、环境隔离和数据边界共同支持耗时测试、依赖安装、跨文件重构和批量修复。
9.7 Externalized / Persistent Task State
Externalized / Persistent Task State 是把任务、依赖、状态和执行证据从对话记录迁移到外部结构化存储的机制。它让任务状态跨会话、跨进程和跨 Agent 持续存在。
任务状态记录当前工作及其推进位置，语义记忆记录可以跨任务复用的知识与经验。两者分别服务执行管理和知识复用，并通过任务编号、规格和工件建立关联。
9.8 Task Lifecycle 与 Durable Execution
Task Lifecycle 是任务从创建到结束的状态模型，通常包含 Queued、Running、Input Required、Completed、Failed 和 Cancelled。状态转换描述任务当前处于什么阶段以及下一步允许发生什么动作。
Durable Execution 是任务在进程、会话或机器中断后从持久状态安全继续的执行能力。Checkpoint、外部副作用记录、错误分类、超时、取消和结果存储共同构成恢复基础。
9.9 Retry、Idempotency 与 Stop Conditions
Retry 是失败后再次执行操作的恢复机制，Idempotency 是同一操作重复执行时不重复产生副作用的性质，Stop Conditions 是自主循环结束或升级给人的条件集合。
重试机制按照瞬时错误、永久错误和需要人工输入的错误选择处理方式。幂等键、去重记录和回滚机制保护提交、发布、支付及外部写入等有副作用的操作。最大迭代数、时间、Token、费用、连续失败阈值和取消入口共同限制自主执行范围。
10. AI Coding 工作流框架
AI Coding 工作流框架是把需求、规格、任务、实现、验证和交付组织成可重复过程的方法或工具。不同框架分别侧重规格管理、生命周期组织、上下文控制、任务状态或迭代执行，因此可以在同一工程体系中组合使用。
OpenSpec 管理系统行为怎样变化，Task Master AI 和 Beads 管理当前工作及其依赖，Ralph Loop 管理任务怎样反复执行。Spec Kit、BMAD、GSD Core 和 Superpowers 组织不同范围的开发过程。组合使用时，规格和任务状态分别保持单一事实来源，各框架按照职责边界交换工件和执行证据。
11. 质量与验证
质量与验证机制把需求、代码和执行结果转换为可以重复检查的证据。验证闭环、测试方法、Grader、Eval、Benchmark、Review、CI 和 Observability 分别承担结果判断、能力评估、回归控制和过程诊断职责。
11.1 可执行验证闭环（有时称 Verification-Driven Development）
可执行验证闭环是 Agent 在“实现、执行验证器、读取证据、修复、回归验证”之间持续迭代的开发机制。完整交付物同时包含代码和可重复执行的构建、测试、类型检查、静态分析、运行日志或界面证据。
验收条件定义目标，验证器检查结果，执行证据驱动修复。受保护的验证规则限制实现 Agent 修改测试、放宽断言或绕过 CI，并让测试结果保持独立性。
11.2 TDD 与 BDD
TDD、BDD、SDD、Property-based Testing 和 Fuzzing 是从不同角度定义行为与验证结果的方法。
SDD 描述目标行为，TDD 和 BDD 把部分行为转化为可执行验证，Property-based Testing 和 Fuzzing 扩展输入覆盖范围。
11.3 Verifier、Test Oracle 与 Grader
Verifier、Test Oracle 与 Grader 是判断任务结果是否满足目标的验证组件。它们分别定义正确结果、执行检查和形成评分。
Deterministic Grader 适合直接检查正确性和安全性，Model Grader 适合评价难以完全编码的质量维度，Human Grader 负责业务与风险判断。Verifier Hacking 表示实现通过削弱或绕过验证器获得通过结果，因此关键验证器属于受保护控制面。
11.4 Agent Evals
Agent Evals 是对完整 Agent 系统进行可重复评估的方法。评估对象包含模型回答、工具调用、环境交互、任务结果、运行过程、成本和安全表现。
Capability Eval 描述系统在给定预算下能够达到的能力上限，Regression Eval 描述系统版本变化是否引入退化。pass@k 表示 k 次尝试中至少成功一次的概率，pass^k 表示 k 次尝试全部成功的概率，两者分别反映搜索能力和执行稳定性。
11.5 Coding Benchmark
Coding Benchmark 是使用固定代码任务集比较模型或 Agent 系统能力的标准化评测方式。评测结果由模型、Harness、工具、预算、数据集版本和运行环境共同产生。
Benchmark 提供标准任务上的横向比较，Repo-level Eval 描述系统在私有项目中的实际表现。训练数据污染、公开答案泄漏、任务缺陷、能力饱和和 Harness 差异都会影响 Benchmark 的区分能力和有效期。
11.6 Review Agent
Review Agent 是使用独立任务上下文检查代码变更、错误、遗漏、兼容性问题和测试缺口的 Agent。它把实现结果作为评审对象，并输出具体问题、影响范围和复现证据。
独立上下文降低评审过程对实现思路的锚定，独立测试和不同验证方法提供更强的正确性证据。Review Agent 的发现属于候选问题，最终结论由测试、静态分析或人工复核共同确认。
11.7 CI as Feedback
CI as Feedback 是把持续集成结果作为 Agent Loop 输入的反馈机制。测试失败、静态分析、Secret Scanning 和依赖漏洞报告会进入下一轮诊断与修复。
CI 同时承担过程反馈和最终合并门禁。CI 配置、验收测试和发布规则属于受保护控制面，权限隔离、代码所有权、分支保护和人工评审防止实现过程降低验证标准。
11.8 Observability
Observability 是使用日志、指标、Trace 和事件理解 Agent 与 Harness 执行状态的机制。它描述任务发生了什么、在哪一步失败、消耗了多少资源以及产生了哪些外部动作。
Observability 负责诊断执行过程，Eval 负责评价任务结果。Trace 数据包含 Prompt、工具参数、源码、个人信息和 Secret 等潜在敏感内容，因此采集范围、脱敏、保留期限和访问控制属于可观测性体系的一部分。
11.9 Traceability、Provenance 与 Audit Trail
Traceability、Provenance、Attestation、Audit Trail 和 Agent Lineage Metadata 是记录需求关系、产生过程和操作责任的证据机制。
这些机制承担不同的证据职责。Traceability 连接工程工件，Provenance 和 Attestation 描述产生过程与声明，Audit Trail 重建操作过程，Lineage Metadata 记录 Agent 系统内部版本信息，结果正确性由验证器和评审判断。
12. 安全与治理
安全与治理是把 Coding Agent 作为真实执行主体进行权限、数据、供应链和责任管理的工程体系。它通过执行边界、不可信上下文防护、软件供应链控制和策略治理限制 Agent 的风险范围。
Repository Instructions 向模型提供行为指引，Sandbox、权限系统和 Policy-as-Code 在模型之外执行确定性安全规则。人工审批保留关键决策权，风险分级控制审批频率，Audit Trail 和 Incident Response 支持事后追踪与恢复。
13. 人机协作角色变化
人机协作角色变化描述 AI Coding 环境中人和 Agent 的职责重新分配。工程师负责目标、取舍、风险和最终验收，Agent 负责搜索、实现、验证和机械处理，双方共同完成需求澄清、调试和评审。
13.1 风险导向的常见分工
风险导向分工按照判断责任、操作可逆性和验证难度分配人机职责。
实际职责会随任务、能力和风险变化。领域经验影响规格准确性、假设识别和验证条件设计，因此人类判断仍然构成高风险任务的责任基础。
13.2 人类控制模式
人类控制模式描述 Agent 执行期间人工决策、监督和干预的不同程度。
任务风险、操作可逆性和验证充分程度共同决定控制模式。高风险和不可逆操作对应更强的人工介入，低风险、可回滚且验证充分的操作对应更高的自动执行程度。
13.3 Autonomy Envelope / Delegation Contract
Autonomy Envelope / Delegation Contract 是一次自主执行的目标、授权、预算、审批、停止、证据和回滚边界。它把 Agent 能做什么、可以自主做多久、被授权产生什么副作用以及失败影响多大分开描述。
Autonomy Envelope 包含目标、范围、工具、数据、目标系统、时间与成本预算、审批动作、完成条件、停止条件、升级条件、交付证据和回滚方式。Capability 的提高不会自动扩大 Authority，最终业务、安全和发布责任仍由组织和责任人承担。
14. 根据问题选择概念和工具
问题与概念的对应关系用于把工程症状映射到解决机制。每类问题通常涉及多个层次，表中的概念共同构成优先分析方向。
pass@kpass^k、Flaky Test、Regression Eval | |
15. 核心术语速查
核心术语速查使用一句话定义汇总全文主要概念。每个定义描述该术语的核心作用和所在层次。
pass@k | |
pass^k | |
知识星球介绍（公认的cpp c++学习地）
星球名字：奔跑中的cpp / c++
专注cpp/c++相关求职领域的辅导
加入星球福利，后续如果有其他活动、服务，不收费，不收费，可以合理赚钱就收取下星球费用，但是不割韭菜，保持初心
如果想了解星球或者有其他疑惑的也可以加阿甘微信：
感兴趣的微信扫下面的码，然后下载知识星球app登录即可
（1）高质量的项目合集
以及最近出的ros机器人项目
同时如果项目，遇到任何困惑也会第一时间进行解答的
（2）高质量精确性八股资料
（3）详细的学习路线
（4）活跃的学习氛围，星球打卡不只是一个形式，而是每天观看，针对同学们的学习情况提出合理化的建议，同时也有高质量的星球微信内部群
（5）星球提问简历修改，提供意见的同时，还会给安排一对一腾讯会议辅导
（6）星球同学offer情况，以及对应学习情况，给大家提供参考
（7）全网最全cpp相关面经整理
（8）编程实战能力提升平台（大家都可以使用的，免费的）
访问网址 cppagancoding.top
星球同学的评价
（9）每周也会进行直播答疑，同时有时也会给星球内部同学开一些知识、路线分享会。
具体可以看B站放的视频，up名字：cpp辅导的阿甘
（10）奖励金激励，会根据大家打卡学习/ 面经打卡整理情况，每个月每个季度发放奖励金。有的人陆陆续续已经获得了数千月的奖励金，是加入星球费用的数十倍了
（11）全网最全的26届校招、27届实习/校招整理表汇总
等等，可能还有一些其他服务，目前没想起来的，以及后续也会增加的服务