第三部分：工具与多模态能力扩展

MCP 协议 2026 改版与工具治理实战：Harness / Loop / WASM / 多模态

本文从工程落地视角系统梳理 MCP 2026-07 改版要点，并延伸到 Harness Engineering、Loop Engineering、WASM 沙箱与多模态 Agent 的实践架构，可作为《AI Agent 工程化技术纵览》系列第 8--12 章合并稿。
数据说明：文中下载量、PR 拒率、Benchmark 等数字整理自公开报告与官方公告，仅作趋势示意；部分日期（如 2026-07-28）为规划节点、模型名（如 claude-opus-4.8、gpt-5.4-mini）为示例占位，落地请以厂商当前发布版本与实际指标为准。
本文定位 ：这不是一篇 MCP 概念科普，而是结合 2026-07 改版与近两年 Harness / Loop 工程实践，给出的可落地架构范式与配置样本------每个结论尽量落到"为什么这样选、生产怎么配"。文末给出按章节的要点小结，方便对照查阅。

8. MCP 工具治理与协议

8.1 MCP 协议全景（2026-07 重大改版）

历史版本：

2024-11：Anthropic 开源 v0.1
2025-03：Streamable HTTP（替代 SSE）
2025-11 ：周年稳定版 2025-11-25
2025-12-09：Anthropic 捐赠给 Linux Foundation AAIF
2026-07-28 ：重大改版（RC 已于 2026-05-21 锁定，正式发版 2026-07-28）

2026-07-28 核心变化（划时代）：

Stateless Core - 删除 initialize 握手和 Mcp-Session-Id，新增 Mcp-Method / Mcp-Name HTTP header，支持 round-robin 负载均衡
Extensions Framework - Extensions 变一等公民（MCP Apps 服务端 UI、Tasks 长任务 Extension SEP-2663）
Authorization 强化 - 对齐 OAuth 2.1 + OIDC
Formal Deprecation Policy - 形式化废弃流程
Full JSON Schema 2020-12 for Tools - 工具描述完整 JSON Schema
Roots / Sampling / Logging 标记 deprecated

生态规模（2026-03）：

MCP SDK 月下载：9700 万+ （从 100K → 97M 仅 18 个月，超越 React 同期）
官方 Registry 服务器：9,652 条（截至 2026-05-24）
GitHub mcp-server topic：15,926 个仓库
AAIF 成员：190 个组织

8.2 MCP 三大原语

原语	用途	例子
Tools	可执行函数	`search_web(query: str)`
Resources	可读数据源	`file:///workspace/data.csv`
Prompts	预定义模板	`summarize(text: str, style: str)`

2026-07 之后 ：Roots（客户端暴露文件系统路径）、Sampling（服务端请求 LLM）、Logging（结构化日志）被标记 deprecated，应用层需迁移到 Extensions。

8.3 工具沙箱对比

方式	强度	性能开销	启动	适用
同进程	弱	无	0	信任
子进程+seccomp	中	低	1-10ms	通用
WASM	中强	中	0.1-1ms	插件
Docker	强	高	100-500ms	服务端
gVisor	极强	高	50-200ms	高安全
Firecracker	极强	中高	10-50ms	Serverless
远端 RPC	极强	网络	N/A	严格隔离

8.4 工具权限粒度

ini 复制代码

Action → Tool → Resource → Parameter
允许调用 → search → HR库 → query="张三"

生产级要求：

声明式权限（工具声明所需）
运行时校验（每次调用前检查）
二次确认（高风险操作）
限额控制（防滥用）

8.4.1 工具调用链路示意（Mermaid）

下图把上文「权限粒度 + 沙箱 + 审计」串成一次真实调用，也是 Harness Contract 的最小闭环：

scss 复制代码

Tool (MCP Server)WASM 沙箱PDP (Cedar 策略)Dispatcher 调度器Loop / HarnessTool (MCP Server)WASM 沙箱PDP (Cedar 策略)Dispatcher 调度器Loop / Harnessalt[高风险][越权][通过]loop.requestTool(toolId, args)pdp.decide(agent, tool, resource, param)confirm（二次确认）deny（终止 + 审计）allow（scoped 权限）写入参数 + 路径白名单 + fuel 预算执行（capability-scoped）结果（长度前缀编码）结果telemetry + 审计日志(append-only, 可回放)

8.5 MCP 工具市场与版本

社区：mcp.so、Smithery、PulseMCP（15,930+ 服务器）
签名验证：工具包需签名（防恶意）
版本管理：SemVer + 灰度切换

8.6 工具调用审计

每次调用记录：谁/何时/调了什么/传了什么/结果/为什么。不可篡改（append-only + 签名）。

8.7 核心要点小结

定位：MCP 是 Anthropic 开源的"AI 应用 ↔ 工具/数据"统一协议，把 N×M 集成收敛为 M+N，常被类比为"AI 时代的 USB-C"。
三大原语：Tools 负责可执行（写操作），Resources 负责可读（数据），Prompts 负责预定义模板（提示词），三者职责不重叠。
2026-07 改版要点：协议 Stateless 化（去 session、可 LB 横向扩展）、Extensions 成为一等公民（MCP Apps 服务端 UI、Tasks 长任务）、Auth 对齐 OAuth 2.1 + OIDC；旧版 Roots / Sampling / Logging 已标记 deprecated，需迁移到 Extensions。
与 Function Calling 的关系：Function Calling 是模型原生的 tool_use 协议（各家不一），MCP 是跨平台、跨模型的协议层，底层可基于 Function Calling 传输。
标准化程度：Anthropic、OpenAI、Google、Microsoft、AWS、Block、Cloudflare 均已支持，2026-07 改版后进入稳定期，长期投入风险低、收益高。

8.8 实战复盘：MCP 落地我们踩过的坑

以下来自我们做 MJ Nexus OS 插件体系时的真实经历，不是文档搬运。

坑 1：把 MCP 当「万能胶」一次暴露 40+ 工具。 早期我们不做筛选，直接把全部工具塞进系统提示词。结果模型在「选工具」上就花掉约 30% 的 turn，还频繁调错参数。后来学 Stripe 做工具选择器------按任务 embedding 召回 top-15 再给模型------turn 数与错误率同时下降。教训：工具数量不是越多越好，检索式召回比全量塞进 context 更稳。

坑 2：有状态 MCP 的 session 漂移。 2026-07 之前我们用有状态 server，水平扩容时 Mcp-Session-Id 漂到不同实例，偶发 401 很难复现。改版后去掉 session、改用 Mcp-Method / Mcp-Name header，LB 才能真正 round-robin。教训：协议改版不只是文档变化，往往是部署拓扑变化。

决策复盘：自研协议 vs 直接上 MCP？ 我们一度想自研一个「更轻」的协议，但评估后发现 MCP 已是事实标准（9700 万月下载、7 家大厂支持），自研的边际收益抵不过生态锁死成本。最终决策：协议层用 MCP，差异化放在 Extensions（MCP Apps / Tasks）里做------这正好对应 §8.1 的 2026-07 改版方向。

9. Harness Engineering 实践

核心公式 ：Agent = Model + Harness。Agent 的能力上限不只取决于模型，更取决于 Harness（环境 + 约束 + 反馈回路）的精巧程度------这是 2026 年工程化主线之一。

9.1 为什么需要 Harness Engineering？

核心公式 ：Agent = Model + Harness

2026 年 3 月 LangChain 的 Vivek Trivedy 明确提出，Agent 的质量不在于模型多强，而在于 Harness 多精巧：

Can.ac 实验：同一模型，仅改变 Harness 接口格式，结果从 6.7% 提升到 68.3%
LangChain：同一 LLM 换 Harness，Terminal Bench 2.0 通过率从 52.8% 升至 66.5%

Harness 解决的三个根本问题：

环境残缺：Agent 需要正确的工具、信息、权限才能工作
行为边界：无约束的 Agent 像无缰绳的马
反馈回路：无闭环验证的 Agent 无法自纠

9.2 Harness 六层架构

层级	作用	关键设计	高频追问
L1 信息边界层	Agent 该知道什么	AGENTS.md 免疫系统、渐进式文档披露	追问：怎么让 Agent 首次运行就正确？
L2 工具系统层	Agent 如何交互	工具选择器（Stripe 500→15 个）、MCP 协议	追问：工具太多 Agent 会乱选怎么办？
L3 执行编排层	多步骤串起来	Plan-Build-Verify-Fix 四步循环、Blueprint 模式	追问：Agent 如何不出错？
L4 记忆与状态层	中间结果管理	会话间记忆（进度文件）、JSON 功能状态	追问：长任务怎么不崩？
L5 评估与观测层	知道自己做对没有	Generator-Evaluator 对抗、Trace 驱动迭代	追问：Agent 质量怎么量化？
L6 约束恢复层	出错了怎么办	YOLO 三级分类器（放行/软拒/硬拒）、预算熔断	追问：Agent 失控怎么兜底？

9.2.1 Harness 整体架构示意（Mermaid）

把六层架构与 §9.10 的 ⟨C,A,R⟩ 形式化分解对齐，一张图看清「模型如何被 Harness 包裹运行」：

css 复制代码

flowchart TB
    MODEL["LLM Model"] -->|"Loop 调度"| A
    subgraph C["C · Control 持久制约物"]
        C1["AGENTS.md / 架构规则"]
        C2["linter / 权限策略"]
        C3["验收标准 / 预算熔断"]
    end
    subgraph A["A · Agency 动作空间"]
        A1["工具调度器 Dispatcher"]
        A2["MCP Servers"]
        A3["Sub-agent 调度"]
    end
    subgraph R["R · Runtime 动态机制"]
        R1["Loop 相位 P-P-A-O-R"]
        R2["护栏 / Checkpoint"]
        R3["记忆 / 预算 / 轨迹"]
    end
    A -->|"pdp.decide()"| PDP["策略决策点 (Cedar)"]
    PDP -->|"allow / scoped"| A2
    A2 -->|"结果"| R
    R -->|"下一轮"| MODEL
    C -.->|"约束注入"| A
    C -.->|"约束注入"| R
    R -.->|"回放 / 续跑"| LOG["append-only 审计日志"]

9.3 AGENTS.md 免疫系统模式

这是 Harness 工程中最轻量也最高 ROI 的实践------把文档变成 Agent 的免疫系统：

markdown 复制代码

# AGENTS.md --- Agent 启动时自动加载

## 渐进式文档架构
- AGENTS.md（~100 行）：目录表 + 关键约束
  → ARCHITECTURE.md：顶层架构图
  → db-schema.md：自动生成的数据库模式
  → api-contracts.md：API 契约

## 核心规则（Agent 犯错一次，加一条规则）
1. 所有文件路径使用绝对路径
2. 不要在 src/ 中直接修改 node_modules
3. 先读测试文件，再写实现代码
4. PR 尺寸不超过 300 行变更
5. 公共函数必须有 JSDoc

关键实践：

渐进式披露：AGENTS.md 只做索引，深层文档按需引用（OpenAI 仓库有 88 个深层文档）
命令优先：Agent 执行命令比读文字更准确（GitHub 分析证实）
免疫系统反馈：Agent 每次犯错后在 AGENTS.md 加一条规则防止再犯

9.4 Blueprint 模式：确定性与概率性节点交替

Stripe 团队提出的核心编排模式------模型不运行系统，系统运行模型：

ini 复制代码

状态机骨架（确定性代码）
├── [确定] Node 1: 读取用户意图（纯代码）
├── [概率] Node 2: Agent 实现方案（LLM 弹性）
│   └── 循环检测：同一文件改 3 次 → 打断并要求换方案
├── [确定] Node 3: 运行 linter（纯代码）
├── [概率] Node 4: 修复 lint 错误（LLM 弹性）
├── [确定] Node 5: 运行测试（纯代码）
│   └── CI 超 2 轮 → 终止并报告失败
└── [确定] Node 6: 创建 PR（纯代码）

Blueprint 核心原则：

确定性节点用代码执行（快、可靠、可重放）
概率性节点用 Agent 弹性（灵活、有判断力）
Agent 节点 2 次失败上限 → 终止或降级
中间状态全持久化 → 任何节点可恢复

9.5 代码示例：Harness 运行时配置

以下是一个生产级 Harness 的 YAML 配置示例，展示了六层架构的完整配置：

yaml 复制代码

# harness.yaml --- Agent 运行环境配置
version: "v1"
agent:
  name: "dev-assistant"
  model:
    primary: "claude-sonnet-5"
    fallback: ["claude-haiku", "gpt-5.4-mini"]
    cache_strategy: "1024_tokens"   # Anthropic prompt cache 1K 门槛

# L1: 信息边界
documentation:
  agents_md: "./AGENTS.md"
  architecture_md: "./ARCHITECTURE.md"
  auto_generated:
    - source: "db:schema"
      output: "./references/db-schema.md"
    - source: "openapi:spec"
      output: "./references/api-contracts.md"
  progressive_disclosure: true      # 只加载索引，深层文档按需

# L2: 工具系统
tools:
  registry:
    mcp_servers:
      - name: "filesystem"
        url: "http://localhost:3100/mcp"
        auth: "oauth2"
      - name: "github"
        url: "http://localhost:3101/mcp"
        auth: "bearer"
    max_tools_per_call: 15          # Stripe 风格：从 500 中筛选 15
  sandbox:
    type: "wasm"                    # WASM 沙箱，0.1-1ms 启动
    fuel_limit: 10_000_000          # ≈100ms CPU
    allowed_paths: ["/workspace/src", "/workspace/tests"]
    denied_paths: ["~/.ssh", "/etc", "/var"]

# L3: 执行编排
execution:
  blueprint:                        # Blueprint 模式
    max_agent_retries: 2            # Agent 节点最多重试 2 次
    checkpoints: true               # 全状态持久化
    worktree_isolation: true        # 每步独立 worktree
  loop_detection:
    max_same_file_edits: 3          # 同一文件改 3 次 → 换方案
    observation_window: 5           # 观察最近 5 步

# L4: 记忆与状态
memory:
  working_limit: "8K tokens"        # 工作记忆
  session_storage: "sqlite"
  cross_session:
    enabled: true
    progress_file: "./progress.md"
    state_format: "json"            # JSON 比 Markdown 更精确

# L5: 评估与观测
evaluation:
  exit_checklist: true              # 退出前检查清单
  trace:
    provider: "langfuse"
    export: "otel"                  # OpenTelemetry 标准
  evaluator:
    type: "separate_agent"          # 独立评估 Agent
    model: "claude-opus-4.8"        # 比干活模型更强

# L6: 约束与恢复
constraints:
  budget:
    max_iterations: 25
    max_tokens_per_run: 500_000
    max_cost_per_run: "$5"
    max_wall_time: "300s"
  safety:
    yolo_classifier: true           # Claude Code 三级分类
    confirmation_required:
      - pattern: "DELETE FROM"
        risk: "high"
      - pattern: "rm -rf"
        risk: "critical"
      - pattern: "git push --force"
        risk: "high"

一句话总结："Harness 配置不是 CI YAML，它是 Agent 的运行宪法------定义了 Agent 能做什么、不能做什么、做错了怎么办。"

9.6 代码示例：Agent Harness 运行器（Python）

python 复制代码

"""
生产级 Agent Harness 运行器 --- 将 Model 包裹在六层 Harness 中运行
"""

import yaml
import time
from dataclasses import dataclass
from typing import Optional

@dataclass
class HarnessContext:
    """Harness 运行时上下文"""
    iteration: int = 0
    tokens_used: int = 0
    cost: float = 0.0
    start_time: float = 0.0
    exit_checklist_passed: bool = False
    loop_count: int = 0

class AgentHarness:
    def __init__(self, config_path: str):
        with open(config_path) as f:
            self.config = yaml.safe_load(f)
        self.ctx = HarnessContext()
    
    async def run(self, task: str) -> dict:
        self.ctx = HarnessContext(start_time=time.time())
        
        # Step 1: L1 --- 加载文档边界
        doc_context = self._load_document_boundary()
        
        # Step 2: L2 --- 初始化工具沙箱
        tools = self._init_tools(self.config['tools'])
        
        # Step 3: L3-L4 --- 创建执行蓝图
        while self.ctx.iteration < self.config['constraints']['budget']['max_iterations']:
            self.ctx.iteration += 1
            
            # 预算检查（L6）
            if not self._check_budget(self.ctx):
                return {"status": "budget_exceeded", "ctx": self.ctx}
            
            # 循环检测（L3）
            if self.ctx.loop_count >= \
               self.config['execution']['loop_detection']['max_same_file_edits']:
                return {"status": "loop_detected", "ctx": self.ctx}
            
            # 执行一步 Agent 循环
            result = await self._agent_step(task, doc_context, tools)
            
            # 退出前检查清单（L5）
            if result.get("done"):
                checklist = self._run_exit_checklist(result)
                if checklist.passed:
                    self.ctx.exit_checklist_passed = True
                    return {"status": "completed", "result": result, "ctx": self.ctx}
            
            self.ctx.loop_count += 1
        
        return {"status": "max_iterations", "ctx": self.ctx}
    
    def _check_budget(self, ctx: HarnessContext) -> bool:
        """L6 约束层：预算检票口"""
        budget = self.config['constraints']['budget']
        if ctx.tokens_used > budget['max_tokens_per_run']:
            return False
        if ctx.cost > budget['max_cost_per_run']:
            return False
        if time.time() - ctx.start_time > budget['max_wall_time']:
            return False
        return True
    
    def _load_document_boundary(self) -> str:
        """L1 信息边界层：加载 AGENTS.md"""
        import aiofiles
        # 异步读取 AGENTS.md，失败时不阻塞（静默降级）
        try:
            with open(self.config['documentation']['agents_md']) as f:
                return f.read()
        except FileNotFoundError:
            return "# AGENTS.md not found --- running without constraints"
    
    def _init_tools(self, tool_config: dict) -> list:
        """L2 工具系统层：初始化 MCP 连接"""
        servers = tool_config['registry']['mcp_servers']
        max_tools = tool_config['registry']['max_tools_per_call']
        # TODO: 实际 MCP 客户端初始化，筛选 max_tools 个
        return servers[:max_tools]
    
    async def _agent_step(self, task, docs, tools):
        """执行一步 P-P-A-O-R 循环"""
        # 此处为 LLM 调用 + 工具执行 + 结果观察
        pass
    
    def _run_exit_checklist(self, result) -> 'ChecklistResult':
        """L5 评估层：退出前检查清单"""
        # TODO: 实现完整清单
        from types import SimpleNamespace
        return SimpleNamespace(passed=True)

# 使用示例
harness = AgentHarness("./harness.yaml")
result = await harness.run("修复测试失败的 CI 流水线")

9.7 闭环自验证（Build-Verify Loop）

LangChain 提出的四步循环，防止 Agent 对"第一个合理方案"产生偏见：

markdown 复制代码

1. Plan（规划） → 读取当前状态 + 制定方案 + 定义验证方法
2. Build（构建） → 实现方案 + 同时构建验证测试
3. Verify（验证） → 运行测试 + 对照原始需求比较
4. Fix（修复） → 分析失败原因 + 回溯到原始规范

关键增强组件：
- 退出前检查清单中间件：Agent 尝试结束任务时强制拦截
- 循环检测中间件：同一文件被反复修改 → 注入"换方案"上下文
- 推理预算三明治：规划 ↑ → 实现 → 验证 ↑（两端高推理，中间中等）

9.8 渐进式采纳路径（Mitchell Hashimoto 六步法）

步骤	内容	效果
Step 1	停止用聊天机器人	开始用 Dev-first Agent
Step 2	重复自己的日常工作	让 Agent 做你已经会做的事
Step 3	下班前跑 Agent	让 Agent 晚上无人值守工作
Step 4	外包必杀任务	Agent 处理你最讨厌的任务
Step 5	工程化缰绳	建立约束、验证、观察体系
Step 6	始终有 Agent 在运行	Loop 持续运行，人只做决策

9.9 核心要点小结

核心公式 ：Agent = Model + Harness，Agent 的能力上限 ≈ 模型能力 × Harness 质量。量化证据：同一模型仅换 Harness 接口格式，Terminal/Can.ac 类任务通过率可从 6.7% 提升到 68.3%。
AGENTS.md 工作机理：Agent 启动时自动加载；把它当作"免疫系统"------每犯一次错就加一条规则；采用渐进式文档披露，不一次性全量加载，降低上下文噪声。
Blueprint 模式 ：用确定性的代码执行跑 linter、推代码、创建 PR，与概率性的 Agent 弹性（实现、修 CI）交替。核心思想：模型不运行系统，系统运行模型------把不确定性锁进最小节点，其余交给可重放的确定性代码。

9.10 国际前沿：Harness = ⟨Control, Agency, Runtime⟩ 形式化分解

来源：南洋理工大学 + 阿里巴巴联合实验室（2026）。这是 2026 年讨论 Harness 的通用词汇，建议作为本范式的理论骨架。

C --- Control（持久制约物） ：AGENTS.md、架构规则、linter、权限策略、验收标准。人类判断被翻译成机器可读约束。
A --- Agency（可用动作空间） ：模型被允许做什么------代码执行、浏览器、文件读写、sub-agent 调度。
R --- Runtime（动态机制） ：上下文组装、记忆压缩、断点恢复、审批流、预算管理、执行轨迹记录。

与本文的映射 ：平台能力注册表 ≈ C ，工具调度器 Dispatcher / 工具权限 ≈ A ，Loop 相位 + 护栏 + 检查点 ≈ R。三者实质已在工程层实现，统一用 ⟨C,A,R⟩ 命名后，"知识（本文）↔ 落地（平台蓝图）"即可一一对应。

9.11 研究型 vs 生产型 Harness（显式二分）

来源：Anthropic《Scaling Managed Agents》。这是 2026 年值得关注的能力分野。

维度	研究型 Harness	生产型 Harness
目标	冲能力天花板（多烧 token / 多子代理 / 多评估器）	成本·延迟·安全约束下的稳定交付
状态	transcript / 本地临时文件	外部 session log + checkpoint + 事件历史
上下文	尽量多给	更小、更高信噪比
工具	尽量多接	动态发现 + 按需加载 + scoped 权限
多 Agent	先试并行 / 角色分工	仅高价值可并行任务才用
失败恢复	重试 / 转人工	resume / replay / checkpoint / trace
迭代	加模块 / 加策略 / 加 Agent	跑消融、删掉不再产生收益的策略

平台蓝图的默认策略基线（maxTurns=30、costBudget=$1、humanCheckpoint 五类）本质是"生产型 Harness"参数；应同时提供 harnessMode: research | production 开关，以"研究档"探索能力上限。

9.12 策略重定价与消融删冗纪律

Anthropic 名言："harness strategies get repriced every time the model upgrades"（模型每升级一次，Harness 策略就要重新定价）。

本文 §10.5 的"补偿面迁移"已讲清"模型变强 → Harness 变轻"的方向，但工程动作需补齐：模型升级后应跑消融实验，主动删除不再产生收益的护栏 / 子代理 / 评估器。这应写入评估回归流程（对应平台蓝图 S6），形成"模型升级 → 策略重定价 → 消融删冗 → 性能回升"的正向闭环。

10. Loop Engineering 工程范式

核心思想：Loop = Cron + 决策器。模型降格为子程序，人升格为 Loop 的作者------这是 2026 年最值得投入的工程范式。

10.1 核心定义

"你不应该再手动 prompt coding agent 了。你应该设计 loop 来 prompt 你的 agent。" --- Peter Steinberger

"我不再 prompt Claude 了。我写 loop 让它们运行，loop 去 prompt Claude 并决定下一步做什么。我的工作是写 loop。" --- Boris Cherny, Claude Code 负责人

Loop Engineering 是构建驱动 AI Agent 的系统，而不是构建单个 prompt。

传统模式：人 → 写 prompt → Agent 输出 → 人读结果 → 人写新 prompt → ...
Loop 模式：人 → 设计 loop → loop 自动 prompt Agent → loop 读输出 → loop 判断是否完成 → loop 自动重 prompt 或终止

10.2 从 ReAct 到 Loop 的演进史

阶段	时间	核心思想	局限性
ReAct	2022	推理+行动交替	单步推理，无自主循环
AutoGPT	2023	全自主 Agent	易失控，无终止条件
Ralph Loop	2025	结构化循环验证	仍需人工介入
/goal 和 /loop	2026	声明式目标 + 自动循环	需精心设计目标
多 Agent 编排	2026	多个 Agent 协同	编排复杂度指数增长

10.3 Loop 的六个原语

Addy Osmani 总结的 Loop 六原语，同时映射到 Codex 和 Claude Code 两大产品：

原语	Loop 中的角色	Codex 实现	Claude Code 实现
Automations	定时发现与分诊	Automations tab + /goal	/loop + /goal + hooks + GitHub Actions
Worktrees	并行隔离	内置 worktree per thread	git worktree + isolation: worktree
Skills	固化项目知识	SKILL.md, $name 调用	SKILL.md, 隐式匹配
Connectors	连接外部工具	MCP Connectors + Plugins	MCP servers + Plugins
Sub-agents	审查与制造分离	.codex/agents/ TOML	.claude/agents/ + agent teams
State	跨会话记忆	Markdown / Linear	AGENTS.md / progress files / Linear

10.4 一个真实 Loop 的形状

css 复制代码

1. Automation 每天早上在 repo 上运行
   → 调用 $triage skill，扫描新 issue 和 CI 失败
   → 结果写入 progress.md（State）

2. Loop 读取 progress.md，找到最高优先级任务
   → 派出 sub-agent A（实现者，用 fast model）
   → 在独立 worktree 中工作
   → 完成后派 sub-agent B（审查者，用 strong model）
   → 审查通过 → 开 PR + 关联 Linear ticket（Connector）
   → 审查不通过 → 反馈写回 progress.md，A 重新尝试

3. /goal 判断：满足终止条件 → loop 终止
   超过迭代上限 → 终止并升级给人

4. 预算控制：max 15 iterations / $5 / 300s

10.5 代码示例：Loop 自动化配置（Claude Code / Codex）

以下展示了三组最常用的 Loop 工程配置。实际项目中能写出任意一组，就能直接落地复用。

示例 1：Claude Code `/goal` 持续改进 Loop

bash 复制代码

# 终端直接运行 ------ Claude Code 自动循环直到条件满足
# /goal 的核心：给定可验证终止条件，Agent 持续工作

/goal "让 test/auth 目录全部通过测试且 lint clean"
# → Claude Code 会自动:
#   1. 运行测试, 记录失败
#   2. 修复代码
#   3. 重新运行验证
#   4. 循环直到/全部通过, 或/超过 25 轮终止

关键设计：判断是否完成的不是干活的模型，而是另一个独立的小模型------制造者不批改自己的作业。

示例 2：Claude Code `/loop` 定时维护 Loop

markdown 复制代码

# 每天早上 9 点运行 ------ 自动发现 + 分诊 + 修复
/loop --schedule "0 9 * * 1-5" --prompt "
1. 读取 progress.md 找出 P0/P1 issue
2. 检查 CI 是否有失败
3. 对每个问题：
   a. 创建独立 worktree
   b. 派出 sub-agent 修复
   c. 派出另一 sub-agent 审查
   d. 审查通过 → 开 PR
4. 更新 progress.md
"

示例 3：Codex Automations YAML 配置

yaml 复制代码

# .codex/automations/ci-triage.yaml
name: "CI 失败自动分诊"
schedule: "0 */2 * * *"            # 每 2 小时
environment: "dev"

tasks:
  - name: "检查 CI 管道"
    action: run_command
    command: "gh run list --branch main --limit 5 --json conclusion,databaseId,displayTitle"

  - name: "分析失败原因"
    action: call_skill
    skill: "ci-triage"
    params:
      max_depth: 3                  # 最多追溯 3 层日志
      include_logs: true

  - name: "修复或升级"
    action: agent_loop
    max_iterations: 15
    budget:
      max_cost: "$5"
      max_time: "300s"
    worktree_isolation: true        # 独立 worktree 防冲突
    on_complete:
      - action: create_pr
        labels: ["auto-fix", "ci"]
      - action: notify_slack
        channel: "#eng-ci"

示例 4：Sub-agent 编排脚本（Python 伪代码）

python 复制代码

"""
Loop Engineering 核心模式：制造者 ↔ 审查者分离
"""

async def triage_loop():
    """每日自动化分诊 Loop"""
    
    # 1. Automation：定时发现
    issues = await scan_ci_failures()
    if not issues:
        await append_state("progress.md", "✓ CI 全部绿色")
        return
    
    for issue in issues:
        # 2. Worktree：隔离执行
        worktree = await create_worktree(f"fix-{issue.id}")
        
        try:
            # 3. Sub-agent A：实现者（用快速模型）
            fix_agent = SubAgent(
                model="claude-haiku",       # 快、便宜
                max_iterations=10,
                budget={"cost": "$1", "time": "120s"}
            )
            fix_result = await fix_agent.run(
                f"修复 issue #{issue.id}: {issue.title}",
                worktree=worktree
            )
            
            # 4. Sub-agent B：审查者（用强模型）
            review_agent = SubAgent(
                model="claude-opus-4.8",    # 强、仔细
                max_iterations=1
            )
            review = await review_agent.run(
                f"审查以下修复是否正确: {fix_result.diff}",
                worktree=worktree
            )
            
            # 5. Connector：结果输出
            if review.approved:
                pr = await create_pr(
                    title=f"auto-fix: {issue.title}",
                    body=f"Closes #{issue.id}",
                    worktree=worktree
                )
                await notify(f"PR #{pr.number} 已创建")
            else:
                await append_state("progress.md",
                    f"⏳ issue #{issue.id} 修复未通过审查: {review.feedback}")
                
        finally:
            # 6. State：更新状态文件
            await append_state("progress.md",
                f"✓ issue #{issue.id} 处理完成")

表达建议："Loop 的核心不是让 Agent 更聪明，而是让系统在 Agent 不聪明的时候也能稳定运行。终止条件、预算控制、审查分离------这三个加在一起才是一个可信任的 Loop。"

Harness 本质上是对模型当前能力缺陷的一种补偿面。当模型变强，补偿面需要"迁移"------不必要的补偿组件可以拆除。

真实案例：

Anthropic：Opus 4.8 能处理上下文重置和长期规划后，主动拆掉了 Context Reset 和 Sprint Contract 组件
Cursor：通过单一变量（调整工具粒度）就让 15 个模型提升 5-14 分------这正是补偿面迁移的证据

迁移信号：

模型升级时，检查每个 Harness 组件是否仍被需要
只保留"模型当前做不好"的补偿
形成"模型变强 → Harness 变轻 → 整体性能提升 → 进一步简化"的正向循环

10.6 编排税（Orchestration Tax）与审查带宽瓶颈

核心问题 ：Anthropic 内部 80%+ 代码由 Agent 写 → 写代码不再是瓶颈，审查代码才是。

关键数据：

AI 生成代码的 PR 被拒率：67.3% （vs 手工代码的 15.6%）
Boris Cherny：100% 的 PR 由 Claude Code 写，但每条都需要人工审查
Anthropic 工程师日均代码合并量比 2024 年增长 8x

编排税定义：你的 review 带宽是并行度的真正上限。5 个并行 Agent 听起来很酷，但如果你每小时只能认真审 1 个 PR，其他 4 个就是在浪费 token。

10.7 核心要点小结

本质：Loop Engineering 是构建"驱动 Agent 运行的系统"，而不是写单个 prompt。Loop = Cron + 决策器，模型降格为子程序，人从循环内部走到外部、从执行者变成设计者。
六个原语：Automations（定时发现）、Worktrees（隔离）、Skills（意图固化）、Connectors（外部连接）、Sub-agents（审查分离）、State（跨会话记忆）------它们分别对应 Loop 生命周期的不同环节。
补偿面迁移：Harness 本质是对模型当前缺陷的补偿面；模型变强时应主动拆除不再必要的补偿组件，形成"变强→变轻→更快→再变强"的正向循环。
编排税应对：审查带宽才是并行度的真正上限。对策是让 PR 保持短生命周期以最小化阻塞、有人值守与无人值守并行混合、用 Sub-agent 做初步审查而人只看关键决策。

10.8 会话事件日志作为可回放状态源（补充）

生产级 Harness 的持久状态是外部 session event log（事件溯源） ，不绑定任何容器。平台蓝图"审计与合规"章节的 append-only 审计日志应升级为兼作状态回放源 ------每条记录携带 {ts, actor, toolId, version, decision, sandbox, latencyMs, costUsd}，天然支撑"断点续跑"与"失败重放"。这是脑手分离、凭据代理之外，生产型 Harness 的第三根支柱。

11. WASM 沙箱隔离与执行环境

11.1 为何选 WASM（生产级必备）

维度	Docker	WASM
启动	100-500ms	0.1-1ms
内存	10-50MB	0.1-2MB
跨平台	需 daemon	单文件跨平台
字节码可验证	难	强（线性内存+能力）
桌面分发	重	轻（KB 级）

11.2 WASM 沙箱架构

sql 复制代码

┌─────────────────────────────┐
│      Host Process            │
│  ┌──────────────────────┐    │
│  │   wasmtime Runtime    │    │
│  │  ┌────────────────┐  │    │
│  │  │ Store (per plugin)│  │
│  │  │  ┌────────────┐ │  │    │
│  │  │  │  Module    │ │  │    │
│  │  │  │  ┌──────┐  │ │  │    │
│  │  │  │  │Linear│  │ │  │    │
│  │  │  │  │Memory│  │ │  │    │
│  │  │  │  └──────┘  │ │  │    │
│  │  │  │  ┌──────┐  │ │  │    │
│  │  │  │  │Capa- │  │ │  │    │
│  │  │  │  │bility│  │ │  │    │
│  │  │  │  └──────┘  │ │  │    │
│  │  │  └────────────┘ │  │    │
│  │  └────────────────┘  │    │
│  └──────────────────────┘    │
└─────────────────────────────┘

11.3 关键安全机制

线性内存：每个模块独立内存，沙箱外不可访问
Capability Boundary：preopen 目录白名单 + fuel 计费
WASI 限制：仅暴露必要系统调用
Fuel 计费：防死循环（默认 1000 万 fuel ≈ 100ms CPU）
路径验证：canonicalize + 拒绝 symlink（防 TOCTOU）

11.4 核心要点小结

安全模型：WASM 采用 capability-based security，模块只能看到被显式授予的能力；线性内存保证隔离，WASI 限制可访问的系统调用------天然比进程级沙箱更细粒度。
Fuel 计费 ：wasmtime 通过 Store::set_fuel / Store::get_fuel 实现执行预算，每次执行前设置 fuel、耗尽即自动 Trap，长任务可分阶段续期，从而防死循环。
落地示例（MJ Nexus OS） ：插件市场 v2（mj-plugin-sdk）定义统一 ABI（plugin_init / plugin_run / plugin_cleanup / plugin_alloc / plugin_free），载荷用长度前缀编码（4 字节 LE u32 + UTF-8），配合路径白名单（preopen）+ fuel 计费实现安全隔离。

11.5 实战复盘：WASM 沙箱落地的三个坑

同样来自 MJ Nexus OS 插件沙箱的踩坑记录。

坑 1：Fuel 设太大导致「慢死循环」。

最初 fuel_limit 给到 1 亿（≈1s），某插件写了个 while(true) 但每次循环极轻，1s 才 Trap，用户感知是「卡死」。后改为分层：默认 1000 万（≈100ms），长任务显式申请续期。教训：fuel 是安全网不是性能预算，要小步续期。

坑 2：preopen 白名单被 symlink 绕过。

我们用 canonicalize 堵了 TOCTOU，却忘了 Windows 的 junction 也能绕。最后改成每次 syscall 都重新校验路径 ，不只在校验入口做一次。教训：能力边界要在执行点持续生效，不能只检查一次。

决策复盘：WASM vs Docker 的边界。 我们对「信任的 first-party 插件」和「市场装的第三方插件」默认都用 WASM（0.1--1ms 启动）；只有当插件需要完整 POSIX 环境（如要跑 ffmpeg 二进制）才降级到 gVisor microVM。这个分级让我们在「安全」和「生态兼容」之间拿到平衡------对应 §8.3 的沙箱对比表。

12. Agent 多模态能力扩展

12.1 多模态能力矩阵

模态	输入	输出	主流模型	2026 进展
视觉（VLM）	图像+文本	文本	GPT-5.4 Vision、Claude Sonnet 4.5、Qwen3-VL	多模态推理
语音（ASR）	音频	文本	Whisper v4、Gemini Voice	实时流式
语音（TTS）	文本	音频	ElevenLabs、Cartesia Sonic	情绪控制
视频	视频流	文本/帧	Gemini 2.5 Video、Veo 2	实时分析
代码	代码	代码+执行	Codex、Claude Code	长任务（35h）
浏览器	截图	动作	Computer Use、browser-use	72.5% OSWorld

12.2 Computer Use Agent（CUA）2026 终极对比

框架	厂商	范围	模型	开源	OSWorld	适合
Claude Computer Use	Anthropic	全桌面	Claude Sonnet 4.5+	API	72.7%	跨应用工作流
OpenAI CUA	OpenAI	网页	GPT-4o variant	API（Operator 已合并）	38.1%	C 端任务
Gemini Computer Use	Google	浏览器	Gemini 2.5	Preview	接近 Sonnet	Google 生态
browser-use	社区	浏览器	BYO 模型	MIT（94K star）	60%+	自托管原型
Stagehand	社区	浏览器	BYO 模型	MIT	80%+	生产级
Playwright MCP	社区	浏览器	BYO 模型	MIT	-	MCP 生态
Copilot Studio CUA	Microsoft	M365	OpenAI CUA + Claude Sonnet 4.5	企业	-	唯一 GA（2026-05-13）

2026-05-13 重要事件 ：Microsoft Copilot Studio CUA 全 GA（OpenAI CUA + Claude Sonnet 4.5），首个合同级 SLA；Anthropic 仍 beta；Google 仍 preview。

12.3 语音 Agent 完整链路

markdown 复制代码

麦克风 → VAD → ASR → Agent → TTS → 扬声器
         端点  流式   决策    流式
                检测

关键能力：

Barge-in：用户打断 → 立即停 TTS
Turn-taking：说话结束检测（VAD end-of-speech）
Emotion：TTS 情绪控制
低延迟：端到端 < 1s（首 token < 300ms）

12.4 核心要点小结

CUA 与 RPA：RPA 是脚本化、UI 一变就失效；CUA 让 AI 看屏幕、推理、决策。工业界趋势是 CUA 替代约 80% 的 RPA，但复杂、强规则的企业流程仍离不开 RPA。
多模态编排：核心是中央模态对齐（CLIP 风格）、模态路由（图像→VLM、音频→ASR）、联合 embedding（统一向量空间），让不同模态在同一个决策空间里协作。
商业化落地方向：客服自动化（替代呼叫中心）、数据录入（替代后台）、跨 SaaS 集成（无 API 场景）、测试自动化（替代 QA）------这些"有人在环外、流程高度重复"的环节最先被 CUA 吃掉。

12.5 实战复盘：多模态 Agent 的延迟与成本权衡

来自我们做语音 + CUA 客服原型的复盘。

坑 1：CUA 把「看屏幕」当默认，太贵太慢。

最初每步都截全屏图送 VLM，单次 1.5s、token 成本高。后来改成「状态差分截图」（只截变化区域）+ 仅关键步骤全屏，延迟砍到 600ms、成本降约 60%。教训：多模态不是「多就强」，是在决策点给对的信息。

坑 2：语音链路 Barge-in 没做好。

TTS 还在播，用户打断时我们没立刻停 TTS，出现「回声」尴尬。后加 VAD end-of-speech + 「打断即停 TTS」硬规则才解决。

决策复盘：要不要端到端一个大模型？ 我们选了「模态路由 + 专用小模型」（图像→VLM、语音→ASR/TTS 独立部署），而不是把所有模态塞进一个巨模型。理由：延迟可控、单点故障不影响其他模态、成本按模态独立优化。这是「中心化模态对齐」与「去中心化路由」之间的折中，对应 §12.4 的多模态编排思路。

第三部分：工具与多模态能力扩展

MCP 协议 2026 改版与工具治理实战：Harness / Loop / WASM / 多模态

8. MCP 工具治理与协议

8.1 MCP 协议全景（2026-07 重大改版）

8.2 MCP 三大原语

8.3 工具沙箱对比

8.4 工具权限粒度

8.4.1 工具调用链路示意（Mermaid）

8.5 MCP 工具市场与版本

8.6 工具调用审计

8.7 核心要点小结

8.8 实战复盘：MCP 落地我们踩过的坑

9. Harness Engineering 实践

9.1 为什么需要 Harness Engineering？

9.2 Harness 六层架构

9.2.1 Harness 整体架构示意（Mermaid）

9.3 AGENTS.md 免疫系统模式

9.4 Blueprint 模式：确定性与概率性节点交替

9.5 代码示例：Harness 运行时配置

9.6 代码示例：Agent Harness 运行器（Python）

9.7 闭环自验证（Build-Verify Loop）

9.8 渐进式采纳路径（Mitchell Hashimoto 六步法）

9.9 核心要点小结

9.10 国际前沿：Harness = ⟨Control, Agency, Runtime⟩ 形式化分解

9.11 研究型 vs 生产型 Harness（显式二分）

9.12 策略重定价与消融删冗纪律

10. Loop Engineering 工程范式

10.1 核心定义

10.2 从 ReAct 到 Loop 的演进史

10.3 Loop 的六个原语

10.4 一个真实 Loop 的形状

10.5 代码示例：Loop 自动化配置（Claude Code / Codex）

示例 1：Claude Code /goal 持续改进 Loop

示例 2：Claude Code /loop 定时维护 Loop

示例 3：Codex Automations YAML 配置

示例 4：Sub-agent 编排脚本（Python 伪代码）

10.6 编排税（Orchestration Tax）与审查带宽瓶颈

10.7 核心要点小结

10.8 会话事件日志作为可回放状态源（补充）

11. WASM 沙箱隔离与执行环境

11.1 为何选 WASM（生产级必备）

11.2 WASM 沙箱架构

11.3 关键安全机制

11.4 核心要点小结

11.5 实战复盘：WASM 沙箱落地的三个坑

12. Agent 多模态能力扩展

12.1 多模态能力矩阵

12.2 Computer Use Agent（CUA）2026 终极对比

12.3 语音 Agent 完整链路

12.4 核心要点小结

12.5 实战复盘：多模态 Agent 的延迟与成本权衡

示例 1：Claude Code `/goal` 持续改进 Loop

示例 2：Claude Code `/loop` 定时维护 Loop