Agent 架构深度解析：原理、工程实践与可借鉴经验

执行摘要

本文基于 Tw93 的深度技术文章《你不知道的 Agent：原理、架构与工程实践》，系统梳理了 Agent 系统的底层架构设计原则与工程实践方法。文章揭示了一个关键洞察：更昂贵的模型带来的性能提升往往被高估，而 Harness（测试验证基础设施）和工具定义质量对系统成功率的影响被严重低估。通过对 Agent Loop 核心实现、五种控制流模式、上下文工程、工具设计（ACI 原则）、记忆系统、多 Agent 组织、评测体系等七个维度的深入分析，本文提炼出 10 条可直接应用于工作的实践经验，涵盖从代码库结构设计到评测体系搭建的完整工程闭环。

核心数据亮点：

• C 编译器项目：16 个并行 Agent、2000 个 Claude Code 会话、$20,000 API 成本、两周内实现可编译 Linux 6.9 的 C 编译器，产出约 10 万行 Rust 代码，通过 99% 的 GCC torture test
• 工具优化效果：Tool Search 使上下文保留率达 95%，Opus 4 工具选择准确率从 49% 提升至 74%；Tool Use Examples 使工具调用准确率从 72% 提升至 90%
• 上下文成本优化：Prompt Caching 可降低约 90% 的缓存部分费用；MCP 工具描述同步到文件夹后，任务总 token 消耗减少 46.9%
• 评测基础设施影响：在 1x 资源限制下基础设施错误率接近 6.5%，放开到 Uncapped 后接近 0%，但模型平均得分几乎无变化

第一部分：Agent 核心架构解析

1.1 Agent Loop：极简而稳定的核心循环

Agent Loop 是 Agent 系统的核心执行引擎，其抽象实现仅需不到 20 行代码。这一极简设计的稳定性体现在：从最小实现扩展到支持子 Agent、上下文压缩和 Skills 加载，主循环基本保持不变，新增能力均通过循环外部叠加而非内部修改实现。

flowchart TD
    A[用户输入] --> B{感知阶段}
    B --> C[构建 Prompt + 工具定义]
    C --> D[调用 LLM]
    D --> E{决策阶段}
    E -->|stop_reason == tool_use| F[行动阶段]
    E -->|stop_reason == end_turn| G[返回最终结果]
    F --> H[执行工具]
    H --> I[反馈阶段]
    I --> J[更新 Messages]
    J --> B
    
    style G fill:#90EE90
    style F fill:#FFD700

这一循环遵循感知 → 决策 → 行动 → 反馈四阶段模式，直到模型返回纯文本为止。关键设计原则是模型负责推理，外部系统负责状态和边界。新能力通过三种方式接入：

1. 扩展工具集和 handler：新增功能封装为工具，不改变循环逻辑
2. 调整系统提示结构：通过提示工程引导模型行为
3. 状态外化到文件或数据库：避免循环体成为巨大状态机

1.2 Workflow vs Agent：控制权归属的本质区别

Anthropic 对这两类系统有明确区分：

文章指出，现实中许多标为 Agent 的产品实际更接近 Workflow，但两者并无高下之分，真正重要的是为任务找到更适合的解决方案。

1.3 五种控制流模式：从线性到协作的完整谱系

大多数 AI 系统均可拆解为以下五种模式的组合：

flowchart LR
    subgraph 模式一[Prompt Chaining 提示链]
        A1[步骤1] --> A2[步骤2] --> A3[步骤3]
    end
    
    subgraph 模式二[Routing 路由]
        B1{输入分类} -->|类型A| B2[处理流A]
        B1 -->|类型B| B3[处理流B]
    end
    
    subgraph 模式三[Parallelization 并行]
        C1[任务] --> C2[子任务1]
        C1 --> C3[子任务2]
        C1 --> C4[子任务3]
        C2 --> C5[聚合结果]
        C3 --> C5
        C4 --> C5
    end
    
    subgraph 模式四[Orchestrator-Workers 编排器-工作者]
        D1[中央Agent] --> D2[分解任务]
        D2 --> D3[工作者1]
        D2 --> D4[工作者2]
        D3 --> D5[综合结果]
        D4 --> D5
    end
    
    subgraph 模式五[Evaluator-Optimizer 评估器-优化器]
        E1[生成器] --> E2[产出]
        E2 --> E3[评估器]
        E3 -->|未达标| E1
        E3 -->|达标| E4[最终输出]
    end

关键洞察：很多场景并不需要完整的 Agent 自主权，将几种模式组合即可满足需求。选择哪种模式应基于任务特性而非技术偏好。

第二部分：Harness 设计——决定系统收敛的关键

2.1 Harness 的四要素框架

Harness 是指围绕 Agent 构建的测试、验证与约束基础设施，包括四个核心部分：

1. 验收基线（Acceptance Baseline）：明确的完成标准和通过条件
2. 执行边界（Execution Boundaries）：资源限制、时间预算、操作范围
3. 反馈信号（Feedback Signals）：自动化验证结果、执行日志、系统状态
4. 回退手段（Fallback Mechanisms）：失败时的恢复策略和降级方案

文章强调一个反直觉的结论：模型虽然重要，但决定系统能否收敛的往往是这些外围工程条件。这一判断在高可验证任务（如代码编写、编译器实现）中最为成立，但在开放式研究、多轮协商等弱验证任务中，模型上限本身仍然更关键。

2.2 百万行代码案例的工程约束

一个由 3 个工程师在 5 个月内完成百万行代码（近 1500 个 PR，传统开发速度 10 倍）的案例，揭示了支撑高吞吐 Agent 开发的关键约束：

约束一：代码库结构作为导航信号 清晰的目录结构、命名约定和模块边界成为 Agent 的隐式引导。如果代码库缺乏结构化约束，Agent 的修改行为也会随之混乱。这要求在使用 Agent 前，先投资于代码库的整洁度。

约束二：约束编码化而非文档化 写在文档中的规范很容易被 Agent 忽略，而被编码进 Linter、类型系统或 CI 规则中的约束才具备可执行性。文档是给人看的，代码是给 Agent 执行的。

约束三：基于执行日志的自验证闭环 Agent 在完成操作后，通过查询执行日志或系统状态来确认修改确实生效，避免仅凭一次生成结果就认为任务完成。这要求系统具备完善的可观测性基础设施。

约束四：最小化合并阻力 在高吞吐开发环境中，等待人工审查的成本往往高于修复小错误的成本。团队需要通过完善的自动化测试体系，真正建立对自动化修改的信任。

2.3 C 编译器实现案例：测试先行的极端验证

另一个更具技术深度的案例是：通过 16 个并行 Agent、约 2000 个 Claude Code 会话、约 $20,000 API 成本，在两周内从零实现一个可编译 Linux 6.9 的 C 编译器，最终产出约 10 万行 Rust 代码，通过 99% 的 GCC torture test。

该项目的成功依赖三个关键工程判断：

高质量测试先行：Agent 只有在有清晰测试的情况下才会朝正确方向优化，否则只会高效地写 Bug。这与传统软件开发中”测试驱动开发”的理念高度一致。

用 GCC 做对照验证：用 GCC 的编译结果作为基准，通过对比和二分定位 Bug，而不是依赖 Agent 互相 Review。这避免了”近亲繁殖”式的错误放大。

角色专业化分工：不同 Agent 分别负责重构、性能优化、代码质量等职责，避免所有 Agent 同时改同一类问题。这种分工类似于传统团队中的角色专业化。

2.4 Autoresearcher：低成本探索的模式

Karpathy 的 Autoresearcher 实验展示了另一种极端简化的 Harness 设计：

flowchart TD
    A[修改 train.py] --> B[运行实验 5分钟]
    B --> C{结果更好?}
    C -->|是| D[Commit 作为新基准]
    C -->|否| E[Revert 直接回滚]
    D --> F[记录结果]
    E --> F
    F --> A

该设计的核心特征：

• 单文件搜索空间：Agent 只能修改 train.py，数据处理和评估脚本只读
• 固定时间预算：每次实验最多 5 分钟，优化目标是在有限时间内取得更好结果
• 失败成本低：实验结果不好直接 Revert，不留下技术债，让 Agent 可以大胆探索

关键洞察：约束条件越清晰，Agent 的优化目标就越明确，加上搜索空间可控，系统跑偏时更容易及时拉回。

2.5 验证难度与任务清晰度的四象限分析

文章用验证难度和任务清晰度两个维度划分了四个象限：

quadrantChart
    title 验证难度 vs 任务清晰度
    x-axis 低验证难度 --> 高验证难度
    y-axis 低任务清晰度 --> 高任务清晰度
    quadrant-1 理想工作区
    quadrant-2 依赖人工审查
    quadrant-3 难以持续产出
    quadrant-4 容易优化错误方向
    
    "代码生成": [0.8, 0.9]
    "单元测试": [0.9, 0.85]
    "编译器实现": [0.85, 0.8]
    "翻译任务": [0.6, 0.7]
    "创意写作": [0.3, 0.6]
    "开放式研究": [0.2, 0.3]
    "多轮协商": [0.4, 0.2]

右上角（高清晰度 + 高可验证性）是最适合 Agent 发挥的区域。Harness 设计的关键在于，只有自动化验证和清晰的目标与参照标准同时具备，Agent 才能真正高效工作。

第三部分：上下文工程——质量优于长度

3.1 Context Rot：上下文腐化问题

上下文工程的关键不是窗口够不够长，而是放进去的东西是否真正相关。Transformer 的注意力复杂度是 O(n²)，上下文越长，关键信号越容易被噪声稀释。

**Context Rot（上下文腐化）**是指当无关内容占到上下文的大头时，Agent 的决策质量明显下滑的现象。很多看起来像模型能力不足的问题，往往可以追溯到上下文组织不当。

3.2 四层信息结构

上下文信息应按用途分层管理：

flowchart TB
    subgraph 常驻层[常驻层]
        A1[身份定义]
        A2[项目约定]
        A3[绝对禁止项]
    end
    
    subgraph 按需层[按需加载]
        B1[Skills]
        B2[领域知识]
        B3[操作流程]
    end
    
    subgraph 运行时层[运行时注入]
        C1[当前时间]
        C2[渠道ID]
        C3[用户偏好]
    end
    
    subgraph 记忆层[记忆层]
        D1[跨会话经验]
        D2[MEMORY.md]
    end
    
    subgraph 系统层[系统层]
        E1[Hooks]
        E2[代码规则]
        E3[确定性逻辑]
    end
    
    常驻层 --> 按需层
    按需层 --> 运行时层
    运行时层 --> 记忆层

关键原则：别把确定性逻辑放进上下文。凡是可以通过 Hooks、代码规则或工具约束表达的内容，都应交给外部系统处理，而不是让模型反复读取。

3.3 三种压缩策略

压缩的保留优先级（应在文档中明确）：

1. 架构决策（不得摘要）
2. 已修改文件和关键变更
3. 验证状态（pass/fail）
4. 未解决的 TODO 和回滚笔记
5. 工具输出（可删，只保留结论）

重要约束：压缩时不得改动标识符（UUID、hash、IP、端口、URL、文件名），必须原样保留。

3.4 Prompt Caching：成本优化利器

Anthropic API 支持对消息内容块标记 cache_control: { type: "ephemeral" }。首次请求建立缓存，之后 5 分钟内相同前缀的请求可直接复用。被缓存部分的费用可下降约 90%，非常适合系统提示较长、调用频繁的 Agent。

缓存命中可通过 response.usage 中的 cache_read_input_tokens 和 cache_creation_input_tokens 判断。

3.5 Skills 模式：按需加载的知识管理

Skills 是上下文工程中非常有效的一种模式，核心思路是系统提示只保留索引，完整知识按需加载。

const systemPrompt = `
可用 Skills：
- deploy: 部署到生产环境的完整流程
- code-review: 代码审查检查清单
- git-workflow: 分支策略和 PR 规范
`;

async function executeLoadSkill(name: string): Promise<string> {
  return fs.readFile(`./skills/${name}.md`, "utf-8");
}

Skills 描述的关键要求：

1. 简短：描述本身会常驻上下文，几十个 token 的差异在高频调用里会持续累积
2. 写成路由条件而非功能介绍：至少说明三件事——什么时候用、什么时候不要用、产出物是什么
3. 包含反例：使用 “Use when / Don’t use when” 格式

3.6 Dynamic Context Discovery

Cursor 把这种策略称为 Dynamic Context Discovery，核心不是预先提供尽可能多的信息，而是默认少给，只在需要时读取。

文件系统成为优质上下文接口的原因：工具调用经常返回大量 JSON，几次搜索就足以堆出成千上万 token。与其在上下文中截断、粘贴或长期保留，不如直接写入文件，让 Agent 通过 grep、rg 或脚本按需读取。

Cursor 在 MCP 工具上的验证：把工具描述同步到文件夹，Agent 默认只看到工具名，需要时再查询具体定义，A/B 测试中任务总 token 消耗减少了 46.9%。

第四部分：工具设计——ACI 原则

4.1 三代演进

工具设计经历了三个阶段的演进：

第一代：API 封装 每个 API Endpoint 对应一个工具，粒度过细，Agent 往往需要协调多个工具才能完成一个目标。

第二代：ACI（Agent-Computer Interface） 工具应对应 Agent 的目标，而不是底层 API 操作。例如不要分别暴露 create_file、write_content、set_permissions，而是直接给一个 create_script(path, content, executable) 一次搞定。

第三代：Advanced Tool Use 在工具设计之上进一步优化：

• Tool Search（动态工具发现）：别把全部工具定义一次性塞给模型，Agent 通过 search_tools 按需发现，上下文保留率达 95%，Opus 4 准确率从 49% 提升至 74%
• Programmatic Tool Calling（代码编排）：让模型用代码编排多个工具调用，中间结果在执行环境中流转不进入 LLM 上下文，token 消耗从约 150,000 降到约 2,000
• Tool Use Examples（示例驱动）：每个工具附带 1-5 个真实调用示例，工具调用准确率从 72% 提升至 90%

4.2 ACI 设计原则

ACI 可类比人机交互设计 HCI，工具设计对 Agent 的影响和界面设计对人的影响一样直接。

参数层防错：

// 差：接受相对路径，Agent 容易传错
read_file(path: string)

// 好：参数名 + 描述强制绝对路径
read_file(absolute_path: "必须是绝对路径，如 /home/user/project/src/main.ts")

返回格式参数化： 工具输出格式未必需要固定，也可以让 Agent 按需指定。Anthropic 内部案例中，把 response_format 做成参数后，单个工具描述从 206 tokens 压缩到 72 tokens。

定义与实现绑定： 使用 Zod schema 可以同时生成 JSON Schema 和 TypeScript 类型，把参数验证和文档约束合并在一处：

const searchTool = betaZodTool({
  name: "search_code",
  description: "在代码库搜索内容，返回匹配行。不适合读整个文件",
  inputSchema: z.object({
    pattern: z.string().describe("搜索模式，支持正则"),
    path: z.string().optional().describe("搜索目录，默认当前目录"),
  }),
  run: async (input) => {  // input 类型自动推导
    return await executeGrep(input.pattern, input.path);
  },
});

4.3 工具数量的克制原则

仅 5 个 MCP 服务器就可能带来约 55,000 tokens 的工具定义开销。工具一旦过多，模型对单个工具的注意力也会被稀释。

调试 Agent 时应先检查工具定义——大多数工具选择错误的原因出在描述不准确，不在模型能力。能用 Shell 处理的、只需静态知识的、更适合 Skill 的，都不需要新增工具。

第五部分：记忆系统——跨会话一致性

5.1 四类记忆的分层架构

flowchart TB
    subgraph 运行时[Agent 运行时]
        A[上下文窗口<br/>messages[]]
    end
    
    subgraph 持久层[磁盘持久层]
        B[Skills 文件<br/>按需加载]
        C[JSONL 历史<br/>完整记录可检索]
        D[MEMORY.md<br/>精选事实注入]
    end
    
    A -.->|会话结束清空| A
    B -->|加载| A
    C -->|检索| A
    D -->|启动注入| A

5.2 ChatGPT 四层记忆实现

作为产品实现参考，ChatGPT 的记忆系统结构出人意料地简洁：

1. Session Metadata：设备、地点、使用模式（不持久化）
2. User Memory：约 33 条关键偏好事实（持久化，每次注入）
3. Conversation Summary：约 15 个最近对话的轻量摘要（持久化）
4. Current Session：当前对话滑动窗口（不持久化）

值得注意的是，它没有使用向量数据库，也没有引入 RAG。对于大多数 Agent，结构化 Markdown 加关键词搜索已具备足够好的可调试性和成本表现，只有当规模超过几千条且确实需要语义相似度检索时，再考虑引入向量检索更合适。

5.3 整合流程的可回退设计

整合上下文的关键不是”把旧消息删掉”，而是”把它们从活跃上下文中安全移出”。

flowchart TD
    A[对话消息流] --> B{tokenUsage >= 50%?}
    B -->|是| C[llmSummarize 待整合消息]
    B -->|否| A
    C --> D[成功?]
    D -->|是| E[摘要追加到 MEMORY.md]
    D -->|否| F[原始消息写入 archive/]
    E --> G[更新 lastConsolidatedIndex]
    F --> G
    G --> A

关键原则：系统只移动指针，不删除原始消息。即使整合失败，还能回到原始存档继续工作。

第六部分：长任务与多 Agent 组织

6.1 Initializer + Coding Agent 模式

长任务最常见的失败不是单步报错，而是 session 结束时任务还没做完。更稳定的做法是拆分为两个角色：

Initializer Agent：只在第一轮运行一次，负责生成 feature-list.json、初始 git commit 和 claude-progress.txt，把任务变成可持久化的外部状态。

Coding Agent：循环执行，每次从进度文件和 git log 恢复现场，定位当前任务，实现一个功能，跑测试，更新 passes 字段，提交代码后退出。

sequenceDiagram
    participant I as Initializer Agent
    participant F as feature-list.json
    participant G as Git
    participant C as Coding Agent
    participant T as Tests
    
    I->>I: 生成 feature-list.json
    I->>G: 初始 commit
    I->>I: 生成 claude-progress.txt
    
    loop 每个功能
        C->>F: 读取当前任务
        C->>C: 实现功能
        C->>T: 运行测试
        C->>F: 更新 passes: true
        C->>G: 提交代码
    end

关键洞察：进度要放在文件里，不要放在上下文里。功能清单用 JSON 不用 Markdown，结构化格式更适合模型稳定修改。

6.2 指挥者 vs 统筹者模式

多 Agent 的主要价值不是单纯多开几个模型，而是把人的持续参与变成对工件的最终审核。

6.3 多 Agent 协作的关键顺序

引入多 Agent 有明确的依赖顺序：

1. 先定协议：结构化通信协议（如 JSONL inbox）
2. 再做隔离：Worktree 隔离文件修改
3. 再建任务图：.tasks/ 记录依赖关系
4. 最后加验证：交叉验证或外部反馈

如果跳过了这个顺序，比如没有任务图就直接引入多 Agent，等于让多个 LLM 在混乱的共享状态上竞争，幻觉和冲突会快速放大。

第七部分：评测体系——比 Agent 更难的是评测 Agent

7.1 三组核心概念

关键洞察：评测不能只看执行记录（Agent 说”订票已完成”），也不能只看最终结果（数据库里确实有订单），两类都要覆盖才能避免”说了但没做到”或”过程走歪了”的问题。

7.2 Pass@k vs Pass^k

两者不可混用：回归测试过于宽松会漏掉问题，能力评测过于严格会让每一次小改动都触发告警。

7.3 评测基础设施 vs Agent 能力

一个经常被误判的现象是：评测环境给的资源越紧（算力、时间预算、环境限制），成功率通常越低，基础设施错误率也越高，这和模型能力完全无关，但在评测结果里会被直接误读为 Agent 退化。

数据显示：在 1x 资源限制下基础设施错误率接近 6.5%，放开到 Uncapped 后接近 0%，但模型的平均得分几乎没有变化。

关键洞察：如果在资源受限的评测环境中看到性能下降，第一步先排查基础设施问题，而不是修改 Agent。

7.4 两层评测体系

第一层：人工抽样标注

• 基于规则采样错误案例、长对话和用户负反馈
• 由人工判断执行质量和失败原因
• 用来摸清失败模式，给第二层提供校准数据

第二层：LLM 自动评估

• 对更大范围的 Trace 做全量覆盖
• 以第一层标注结果作为校准依据
• 只跑第二层，评分标准很容易漂移

两层要一起用。全量运行在线评测的成本通常不低，建议对 10%-20% 的 Trace 运行在线评测，采样按规则路由：负反馈 100% 进队列、高成本对话优先、时间窗口采样、变更后 48 小时全量审查。

第八部分：可落地的十条工作经验

基于以上分析，提炼出可直接应用于工作的十条经验：

8.1 模型选择：性价比优先

经验：更贵的模型带来的提升，很多时候没有想象中那么大。

实践：

• 在 Harness 和验证测试质量达标的前提下，优先使用性价比更高的模型
• 把预算投入到测试基础设施而非更昂贵的 API 调用
• 对高可验证任务，模型间的差距会进一步缩小

8.2 调试优先级：工具定义优先

经验：调试 Agent 时应优先检查工具定义，因为多数工具选择错误都出在描述不准确。

实践：

• 建立工具定义 review 流程，确保描述清晰、边界明确、示例充分
• 添加 Tool Use Examples 可显著提升准确率（72% → 90%）
• 工具数量要克制，能用 Shell 处理的、只需静态知识的，都不需要新增工具

8.3 评测系统健康：先查基础设施

经验：评测系统本身的问题，很多时候比 Agent 出问题更难发现。

实践：

• 建立评测基础设施监控，区分 infra error 和 Agent error
• 资源受限环境下看到性能下降，先排查基础设施而非修改 Agent
• 定期进行人工抽查，不只看聚合数字

8.4 代码库设计：结构即导航

经验：代码库结构是 Agent 的导航信号，清晰的目录结构、命名约定和模块边界会成为 Agent 的隐式引导。

实践：

• 在使用 Agent 前，先投资于代码库的整洁度
• 建立清晰的目录结构和命名规范
• 模块化边界明确，减少 Agent 的理解成本

8.5 约束管理：编码化优于文档化

经验：写在文档中的规范很容易被 Agent 忽略，而被编码进 Linter、类型系统或 CI 规则中的约束，才具备可执行性。

实践：

• 将规范转化为自动化检查（ESLint、TypeScript、Prettier、CI/CD）
• 减少依赖文档描述，增加依赖代码约束
• 在 PR 流程中强制执行自动化检查

8.6 失败成本：低才能大胆探索

经验：失败成本低才能大胆探索不确定方向，Autoresearcher 的设计让”结果不好直接 Revert”成为可能。

实践：

• 设计可快速回滚的实验流程
• 使用 Git 分支隔离实验性修改
• 建立清晰的实验标准和验收条件

8.7 工作区定义：清晰约束 + 自动化验证

经验：只有自动化验证和清晰的目标与参照标准同时具备，Agent 才能真正高效工作。

实践：

• 将任务推进到同时具备清晰约束和自动化验证的状态
• 对依赖人工验证的任务，逐步建立自动化检查
• 对方向不清晰的任务，先明确目标再投入 Agent

8.8 上下文管理：质量优于长度

经验：上下文工程的关键不是窗口够不够长，而是放进去的东西是否真正相关。

实践：

• 采用 Skills 模式，系统提示保留索引，完整知识按需加载
• 实施 Dynamic Context Discovery，默认少给，只在需要时读取
• 明确压缩时的保留优先级，确保关键信息不丢失

8.9 工具设计：目标导向而非 API 导向

经验：工具应对应 Agent 的目标，而不是底层 API 操作。

实践：

• 遵循 ACI 原则，一次调用完成一个目标
• 提供清晰的 Use when / Don’t use when 描述
• 使用 Zod Schema 绑定定义和实现，确保类型安全

8.10 进度管理：外化到文件系统

经验：进度要放在文件里，不要放在上下文里。

实践：

• 使用结构化格式（JSON）记录任务状态
• 通过文件系统和 Git 记录传递状态
• 设计可重入的 Agent 流程，支持从断点恢复

第九部分：批判性评估与适用边界

9.1 这些经验的适用边界

上述经验主要在高可验证任务（代码生成、单元测试、编译器实现等）中得到验证，在以下场景需要调整：

不适用或需调整的场景：

• 开放式研究：目标不清晰，难以定义明确的验收标准
• 创意写作：质量标准主观，难以自动化验证
• 多轮协商：依赖对方反应，状态空间过大
• 弱验证任务：模型上限本身比工程约束更关键

9.2 实施这些实践的前提条件

必要的基础设施：

1. 完善的测试框架和自动化验证能力
2. 可观测性系统（日志、指标、追踪）
3. 代码库的基础整洁度
4. 版本控制和回滚能力

团队能力要求：

1. 理解 Agent 的工作原理和局限性
2. 具备 Prompt Engineering 基础能力
3. 能够设计和维护评测体系
4. 有处理 Agent 失败和调试的经验

9.3 潜在风险与缓解策略

第十部分：前瞻与总结

10.1 技术演进趋势

短期（6-12 个月）：

• Prompt Caching 等成本优化技术将成为标配
• Skills 和 MCP 的混合使用模式将趋于成熟
• 评测基础设施的工具化程度将显著提升

中期（1-2 年）：

• 多 Agent 协作框架将标准化
• 上下文压缩和记忆管理将出现最佳实践
• ACI 设计原则将被更多框架原生支持

长期（2-3 年）：

• 模型能力的提升可能改变部分工程权衡
• 但 Harness 和基础设施的重要性将持续存在
• 人机协作模式将从”指挥”向”统筹”演进

10.2 核心结论

本文通过系统分析 Tw93 的深度技术文章，揭示了 Agent 工程实践中的关键洞察：

1. Agent Loop 的极简稳定性：核心循环不到 20 行代码，新增能力通过外部叠加而非内部修改实现
2. Harness 的决定性作用：在高可验证任务中，测试验证基础设施的质量比模型能力更关键
3. 上下文质量优于长度：Context Rot 是常见问题，Dynamic Context Discovery 和 Skills 模式是有效解
4. 工具设计的 ACI 原则：工具应对应目标而非 API，描述准确比数量多更重要
5. 评测体系的双重挑战：既要测准 Agent，也要保证评测系统本身的健康

最终，Agent 工程的成功不在于使用最先进的模型，而在于建立清晰的约束、完善的验证和持续优化的迭代闭环。这些原则不仅适用于 Agent 开发，也对传统软件工程具有借鉴意义。

参考来源

1. Tw93 - 你不知道的 Agent：原理、架构与工程实践 - 核心内容来源
2. Anthropic - Building effective agents - Workflow vs Agent 定义
3. Anthropic - Demystifying evals for AI agents - Agent 评测方法论
4. OpenAI - Codex CLI 技术报告 - 百万行代码案例分析
5. Karpathy - Autoresearcher - 低成本探索模式
6. Cursor - Dynamic Context Discovery - 上下文优化实践
7. Vercel - AI SDK Documentation - 工具设计最佳实践
8. Claude Code - Official Documentation - Agent 实现参考

本报告基于公开技术文章整理分析，内容仅供学习参考。