Agent 时代开发环境的核心技术依赖：从意图表达到异常干预

从"是什么"到"依赖什么"

这是 AI 时代开发环境三部曲的第三篇：

1. Factory Missions：真正能交付的多 Agent 架构 — Agent 系统能自主构建什么
2. AI 时代，开发者是否还需要 IDE？ — 开发者的角色从"写代码"转向"定意图 + 管异常"
3. 本篇 — 这两个新角色需要什么技术基础？

前两篇描绘了一个愿景：开发者不再逐行写代码，而是定义"什么算对"（意图表达），并在 Agent 系统偏离轨道时介入（异常干预）。但愿景和落地之间有一个 gap——这些新角色需要什么工程工具？

答案可能会让你意外：最重要的依赖不在 AI 领域，在传统软件工程工具的升级。

NII Shonan 222 的启示

2025 年 10 月，33 位来自 SE、AI、HCI 领域的顶级学者在日本湘南会议中心召开闭门研讨会（Shonan Meeting No.222），主题正是"The Future of Development Environments with AI Foundation Models"。会议产生了四个 breakout 组，其中 Group 2（"Evolution"）提出了五个关键辟谣，这对我们讨论技术依赖至关重要：

1. "GenAI 将取代所有软件工程师" — 错。编译器、IDE、开源库都曾被预言消灭程序员，每次都是产能提升、需求同步膨胀。
2. "Prompt 是新的源代码" — 错。源码是目前唯一能确定性重现同一程序的表示。同一个 prompt 在不同模型版本下产出不同代码。
3. "Vibe coding 是唯一流程" — 错。原型阶段表现出色，但严格的性能/隐私/安全约束尚未验证。
4. "新项目经验可以迁移到现有系统" — 错。已有系统的规模与复杂性与 greenfield 完全不同。
5. "再来一个 Agent 就解决了" — 错。软件开发的根本不确定性需要人类协调。

其中第二条直接定义了技术依赖的核心：当 Prompt 不能当源码用，确定性工具就变成了最高价值的资产。

四层技术依赖图

把"意图表达 + 异常干预"这两个核心角色拆开，映射到具体的技术栈：

第一层：意图表达的技术依赖

意图表达不是"写 prompt"——是以可验证的方式精确描述"什么算对"。

① Behavioral Contract DSL（可执行规格语言）

自然语言太模糊。"用户登录后应看到 dashboard"——这是期望，不是规格。真正的规格需要：

• 前置条件：认证通过、session 有效、权限为 user
• 后置条件：DOM 中存在 dashboard-container、URL 为 /dashboard
• 跨 cut 约束：此变更不得破坏 VAL-CROSS-001（认证门控定价页）
• 验证工具：agent-browser，截图 + 网络请求断言

Factory 的 Validation Contract 是最接近的实现：

### VAL-AUTH-001: Successful login
A user with valid credentials submits the login form
and is redirected to the dashboard.
Tool: agent-browser
Evidence: screenshot, network(POST /api/auth/login -> 200)

但这本质上还是自然语言 + 半结构化标注的混合体，没有形式化语义。最近似的学术成果是 Gherkin（BDD 框架的规格语言）和 Alloy（形式化建模语言），但都离"让 Agent 可验证地理解意图"有距离。

② Ambiguity Detector（规格歧义检测）

Shonan Group 4 提到了"compiler for natural language"的概念——一个能检测规格中歧义的系统：

• "用户应该能快速找到功能"中的"快速"——是 100ms？1s？主观感受？
• "系统应正确处理异常"——哪些异常？怎么算正确处理？
• "保持与现有风格一致"——什么风格？谁的风格？

在人类团队中，这类歧义通过讨论解决。在 Agent 系统中，歧义会直接转化为 bug——Worker 对歧义规格的"合理但错误的解释"。

③ Intent VCS（语义级意图版本管理）

源码有 git。Validation Contract 呢？

• 核心场景：你的 Validation Contract 从 v1（"登录用邮箱"）变到 v2（"登录用邮箱或手机号"），系统必须能 semantic diff 这个变更，回答："哪些已完成的 feature 声称满足了被修改的断言？哪些需要重新验证？"
• 类比：不是 git diff on text，而是语义级 diff——理解 "auth method 增加一个选项" 和 "auth method 替换" 的区别
• 现状：完全不存在。最接近的是亚马逊的 contract-based testing 研究

④ Spec↔Impl Traceability（断言到实现的追溯）

当 VAL-AUTH-001 失败，你需要瞬间回答：

• 哪些 Feature 声称满足这个断言？
• 哪些 Worker 实现了这些 Feature？
• 它们的 Handoff 中记录了什么警告？
• 最近的哪些 commit 触及了相关代码路径？

这需要一条完整的追溯链：Validation Contract → Feature-to-assertion mapping → Git commits → Worker Handoff records → Agent trajectory。Factory 有雏形（Feature 声明覆盖哪些 assertion），但追溯链不完整。

第二层：异常干预的技术依赖

异常干预不是"看 log 找 bug"——是在 Agent 的决策轨迹中定位错误选择。

⑤ Agent Trajectory Observability（轨迹可观测性）

这不是传统的 APM。你需要三种专属能力：

LangSmith 和 Weights & Biases 有基础 tracing，但完全缺少决策标注层和上下文毒化量化。

⑥ Handoff Pattern Analyzer（异常模式分析器）

在 Factory 的 Slack clone 构建中：63 个 Worker 各产出结构化 Handoff，Validator 发现 81 个 issue，Orchestrator 生成 21 个 Fix Feature。人类不需要逐条审查——需要的是模式识别：

• "有 7 个 Worker 在 database migration 上遇到了相同的 schema 冲突"
• "连续 3 个 Feature 的架构选择偏离了最初定义的 pattern"
• "Validator 在最后 2 个 Milestone 发现的阻塞问题数量是前 4 个的 3 倍——系统在退化？"

现状：完全不存在专用工具。

⑦ Architecture Drift Detection（架构漂移检测）

这是被严重低估的依赖。Agent 串行执行 63 个 Feature 的过程中，早期 Worker 的架构选择可能被后期 Worker 不经意地违反：

• 依赖图是否仍然完整？
• 接口契约是否被破坏？
• 抽象层是否被穿透？（底层模块直接调用了应被封装的上层 API）

现有静态分析工具（ArchUnit、Dependency Cruiser）可以做架构一致性检查，但它们是为人类开发者设计的——需要手动定义规则。AI 时代需要的是零配置自动适配 Agent 代码库的架构漂移检测。

⑧ Intervention Authorization Protocol（干预授权协议）

一个常被忽视的工程问题：Orchestrator 在什么条件下必须暂停等人类？什么条件下可以自主继续？

• "当 Validator 发现 blocking issue，且涉及的代码超过 500 行 → 暂停"
• "当 blocking issue 匹配已知 fix pattern，且涉及代码少于 100 行 → 自动生成 Fix Feature 并继续"
• "当同一个 assertion 连续 3 轮验证失败 → 暂停，可能存在规格错误"

这需要一个声明式的干预策略语言。Factory 的 Mission Control 有简单阻塞逻辑（"handoff issues not addressed → block progress"），但没有策略语言——规则是硬编码的。

第三层：确定性基础——被 G2 重点强调的"仲裁者"角色

Shonan G2（Reid Holmes、Earl Barr 等）的论证在这里最有力量。这些工具以前是"帮开发者写更好代码"。在 AI 时代，它们的角色彻底变了：变成 Agent 生态系统中唯一的无偏见真相来源。

这有一个反直觉的结论：未来开发者最重要的技术投资可能不在 AI 工具上，而在确定性 SE 工具的升级和集成上。因为只有这些工具能从 Agent 产生的海量不确定代码中提取确定性信号。

第四层：人机协调界面

当前最薄弱的层——几乎不存在专用工具。

⑨ Conflict Topology Visualization（冲突拓扑图）

当多个 Worker 修改重叠的代码区域，或 Validator 与 Worker 对"什么是正确"产生分歧——人类需要看到的是冲突图，不是文本日志。哪个 Worker 改了哪些文件？哪些修改之间有语义冲突风险？git merge conflict 有可视化，但 Agent 级别的语义冲突没有。

⑩ Validation Gate Dashboard（验证门控面板）

Factory 的 Mission Control 是最接近的实现——显示每个 Milestone 的验证状态、失败的断言、覆盖率变化、资金消耗进度。但它是闭源产品，且是为 Factory 的特定架构设计的。通用验证门控面板的标准尚未形成。

成熟度全景

12 项核心技术依赖中：6 项完全不存在，4 项仅有雏形，仅 2 项相对成熟。这就是意图表达 + 异常干预这两个未来角色要真正落地面临的基础设施 gap。

三个最重要的结论

① 确定性工具从"辅助"升级为"仲裁者"

当 Agent 产出 38,800 行代码，你不能用另一个 AI 来判断质量——它可能共享相同的训练数据偏见。只有 git、确定性构建、静态分析这些工具能给出无偏见判断。它们在 AI 时代从 nice-to-have 变成了 critical infrastructure。

② 意图工程（Intent Engineering）是最大的未开发领域

现有的 DSL（Gherkin、Alloy）面向人类开发者。我们需要的是面向 Agent 生态系统的规格语言——能让 Orchestrator 分解成 Feature、能让 Worker 无歧义理解、能让 Validator 可执行验证。Factory 的 Validation Contract 证明了需求存在。但形式化方案仍是空白。

③ 12 项依赖中缺失 6 项——这是一个巨大的创业和科研机会

回头看那 12 行表格。6 个红色标记不是 bug——是机会地图。Behavioral Contract DSL、Ambiguity Detector、Intent VCS、Handoff Pattern Analyzer、Intervention Authorization、Conflict Topology Visualization——每一个都是新工具品类的潜在定义者。

系列文章：

1. Factory Missions：真正能交付的多 Agent 架构
2. AI 时代，开发者是否还需要 IDE？
3. 本文 — Agent 时代开发环境的核心技术依赖

引用：

• NII Shonan Meeting Report No.222 — "The Future of Development Environments with AI Foundation Models", October 2025. PDF
• Theo Luan — "How Missions Work", Factory Engineering Blog, April 2026. factory.ai