# 企业级 AI Agent 应用工程 — 12 周学习计划

> 目标：能独立交付**进入企业业务流程、可运营、可验证**的 Agent 应用，而不是造 Harness 平台或 Infra。
> 主线：**业务任务 → Agent Contract → 执行编排 → 上下文与能力 → 受控行动 → 治理 → 评估调优 → 规模化交付**。

## 0. 材料与假设

### 0.1 三份输入

| 来源 | 用途 | 具体位置 |
|---|---|---|
| 《AI Agent Handbook · 企业级智能体架构与工程实践》 | 架构与工程体系主线 | [在线阅读站](https://aliyun.github.io/ai-agent-handbook/) · [仓库](https://github.com/aliyun/ai-agent-handbook) |
| 《深入理解 AI Agent》306 页 | 机制原理补深（上下文/工具/评估/后训练） | `/docs/深入理解 AI Agent - 设计原理与工程实践.pdf` |
| 招聘看板 `https://xu.donglab.asia` | 能力信号校准 + 硬性验收指标 | `data/dashboard.json`、`assets/app.js` |

**数据基线（2026-10-28 快照，`ai_agent_hunter/data/jobs.db`）**

| 项 | 值 |
|---|---|
| 抓取区间 | 2026-10-22 ~ 2026-10-28（首轮全量 2214 + 持续增量追踪） |
| 全量岗位 | 2284 条，10 家：字节 1338 · 美团 219 · 百度 202 · 腾讯 178 · 网易 155 · 阿里 67 · MiniMax 43 · 智谱 40 · 月之暗面 32 · DeepSeek 19 |
| **本计划采用口径** | **应用侧工程岗 576 条**：标题命中 Agent/智能体/Harness/Runtime/Context/MCP/Coding/AI Native/大模型/LLM/AIGC，且剔除产品经理、运营、销售、算法研究、实习 |
| 应用侧公司分布 | 字节 334（58.0%）· 腾讯 73（12.7%）· 美团 47（8.2%）· 阿里 47（8.2%）· 百度 31（5.4%）· 网易 14（2.4%）· MiniMax 12（2.1%）· 月之暗面 9（1.6%）· 智谱 5（0.9%）· DeepSeek 4（0.7%） |
| 噪声/无关 | 21 条（HR、生态合作、标注运营等） |

> **样本偏差须知**：字节占 58.0%，其 RAG（45.5%）、Go/Java（~25%）、C++（11.4%）、Multi-Agent（27.8%）拉高了大盘均值；阿里（MCP 38.3%、Context 57.4%、沙箱 36.2%）、美团（Eval 59.6%、Memory 46.8%、AI Coding 34.0%）与独角兽（Harness/Code Agent/沙箱系统栈）则代表了更高浓度的架构前沿。读下文频次时，把「字节拉动」和「全市场共识」分开看。

### 0.2 本计划的定位假设

若下列任一假设不成立，先改这几行再执行：

- **定位**：企业 Agent 应用研发/交付（Agent Engineer、AI Native 研发、业务 Agent 落地），不做 Harness 平台内核、不做沙箱弹性计算、不做推理引擎。
- **周期**：12 周，每周 10–15 小时（约 130–180 小时总量）。
- **技术栈**：Python 为主（编排、工具、评估），TypeScript 补交互与前端，Docker 做工具隔离；**不要求 Go/Rust**。
- **代码策略**：实现代码可由 AI 生成，本人对**架构决策、边界划分、失败归因、指标口径**负最终责任。每周的验收点都设计成"你能讲清并做出判断"，而不是"你能手写出来"。
- **产出形态**：本文件是唯一的学习主线。旧的分章精读计划已移除。架构手册查 [阿里 AI Agent Handbook 在线阅读站](https://aliyun.github.io/ai-agent-handbook/)；机制细节查本地《深入理解 AI Agent》PDF 对应章节。

### 0.3 与招聘信号的对应关系

#### 0.3.1 应用侧 576 条技能频次（2026-10-28 最新快照）

标题 + 描述 + 要求全文匹配，一岗可命中多项（基准为 576 条严格应用侧工程岗；括号内为含微调/工程全集的 811 条大口径数据）。

| 梯队 | 信号 | 命中 (576) | 占比 (576) | 宽口径 (811) | 趋势与解读 |
|---|---|---:|---:|---:|---|
| **准入项** | Python | 316 | 54.9% | 23.7%* | 业务编排、评测闭环与数据主力语言（*宽口径中多写语言三选一） |
| | Java | 224 | 38.9% | 18.7% | 阿里/美团主力企业系统粘合剂 |
| | Go | 180 | 31.2% | 24.5% | 字节/独角兽高性能 Agent 调度底座 |
| **第一梯队** | 评测 (Eval) | 293 | 50.9% | 56.6% | **断层第一工程信号**，过半大厂硬性卡点（LLM-as-a-Judge/Rubric） |
| | RAG | 210 | 36.5% | 37.9% | 业务厂刚需（字节/阿里/美团/网易 >40%），独角兽趋近 0% |
| | Prompt / 结构化 | 187 | 32.5% | — | 结构化输出（JSON Schema）与严谨提示词设计 |
| | Memory (记忆) | 182 | 31.6% | 33.7% | 会话摘要、跨任务多级记忆与状态持久化 |
| | 分布式 / 并发 | 178 | 30.9% | 28.4% | 工程基本功：异步并发、微服务与高可用治理 |
| | 上下文工程 | 161 | 28.0% | 30.7% | Context Engineering、窗口预算与按阶段装配 |
| | **AI Coding (新增)** | 139 | 24.1% | 21.8% | **最新暴增信号**：AI-Native 研发、Claude Code/Cursor/TRAE |
| | Skill 资产化 | 134 | 23.3% | 24.8% | 稳定高于 MCP，工具与流程的能力资产化封装 |
| | 成本 (Token) | 123 | 21.4% | 21.0% | 上线必审指标，Token/算力成本精细化归因 |
| | MCP | 120 | 20.8% | 16.4% | 跨系统标准化工具接入协议，阿里/网易/智谱激增 |
| **第二梯队** | Multi-Agent | 111 | 19.3% | 26.1% | 多智能体协作、群智分工（字节/阿里突出） |
| | C++ | 104 | 18.1% | 8.5% | 字节（12.4%）风控/CyberAgent/底座，百度（11.9%） |
| | 可观测 (Trace) | 104 | 18.1% | 18.2% | Langfuse/OTel 链路追踪与执行轨迹分析 |
| | Harness | 100 | 17.4% | 9.9% | 运行底座与执行外壳（阿里 30%、独角兽 10%） |
| | 高可用 / 容灾 | 91 | 15.8% | 28.4% | 生产级稳定性与故障恢复 |
| | 权限 / 安全 | 89 | 15.5% | 30.2% | 越权防御、敏感出站拦截与审计 |
| | 多模态 (VLM) | 89 | 15.5% | — | 视觉/语音/文档混合形态 Agent |
| | 延迟 (Latency) | 75 | 13.0% | 12.8% | 流式传输（SSE）与首字/整任务响应时延 |
| | 知识库 | 68 | 11.8% | — | 企业私域知识沉淀与混合检索 |
| | 沙箱 (Sandbox) | 61 | 10.6% | 11.0% | 阿里（28.3%）、腾讯（15.6%）、独角兽代码执行隔离 |
| | ReAct / 规划 | 61 | 10.6% | 42.0%* | 推理规划循环（*宽口径中包含 Planning/思维链占 42.0%） |
| **高门槛/稀缺** | 长程 / 状态机 | 47 | 8.2% | 12.1% | 超长任务断点续跑、权威状态机，实战与面试分水岭 |
| | SFT / 微调 | 44 | 7.6% | 36.4%* | 模型后训练判据与轻量对齐（*算法/后训练岗占比高） |
| | 压缩 / 剪枝 | 38 | 6.6% | — | 上下文窗口压缩与修剪 |
| | 审计 | 38 | 6.6% | — | 执行行为全链路可追溯与合规 |
| | 评测集 / Benchmark| 37 | 6.4% | — | 业务黄金集与 Badcase 回归包 |
| | Agent Runtime | 35 | 6.1% | 11.3% | 腾讯云重点发力（云端 Agent 运行时与托管平台） |
| | 灰度 / A/B | 28 | 4.9% | — | Agent 提示词/模型/工具版本的灰度发布 |
| | Agent Loop | 27 | 4.7% | — | 显式自主循环 |
| | A2A (Agent-to-Agent)| 20 | 3.5% | — | 跨系统/跨主体智能体互通协议 |
| | Human-in-the-loop | 11 | 1.9% | 3.7% | 高风险动作人机审批与阻断恢复 |
| | KV Cache | 7 | 1.2% | — | 缓存亲和度优化 |
| | Subagent | 6 | 1.0% | — | 主从子智能体任务委派 |

**七条必须记住的读法与趋势**：

1. **语言是并列准入，不是专项门槛。** 岗位大多要求「Go、Java、Python 中至少一门」。Python 是 Agent 应用层和评测默认底色；阿里/美团偏好 Java（对齐老业务）；字节/独角兽偏好 Go。**结论：选定一门写透，不为面试频繁换栈。**
2. **评测（Eval）占比破 50%，成为全行业第一卡点。** 评测从 36.9% 攀升至 50.9%（含评估词汇达 56.6%），阿里（66.7%）、美团（66.1%）、腾讯（60.0%）、字节（54.4%）全面超半数。行业已从「Demo 能不能跑」转向「任务成功率是多少、Rubric 标准怎么定、Agent-as-a-Judge 自动化回归」。
3. **AI Coding / AI-Native 成为全新爆发点（24.1%）。** 美团（AI Agent Builder）、字节（AI Native 全栈）、智谱（GLM Code Agent）、阿里（Aone Ground）直接在 JD 中明确要求掌握 Claude Code、Cursor、TRAE，并将构建 Code Agent 自动化工作流作为核心考核项。
4. **Skill (23.3%) 与 MCP (20.8%) 成为能力暴露的行业标准。** 阿里（MCP 35.0%）、网易（MCP 41.2%）、独角兽（MCP 18.4%）快速普及 Model Context Protocol。工具硬编码正在被「标准协议 + 能力资产」取代。
5. **RAG 出现明显分化。** 传统大厂（网易 52.9%、阿里 45.0%、字节 44.9%、美团 38.7%）依赖 RAG 对接企业私域知识；而模型独角兽（DeepSeek、智谱、月之暗面）在 Agent 岗中 RAG 占比趋近于 0%，全力押注长上下文与环境原生交互。
6. **成本（21.4%）与可观测（18.1%）是上线硬门槛。** 成本归因（Token/调用开销）和 Trace（链路追踪）是衡量企业 Agent 是否能规模化交付的试金石。
7. **低频词是高门槛分水岭。** 长程/状态机（8.2%）、沙箱（10.6%）、HITL（1.9%）虽然频次低，但凡是出现该词的岗位，均为核心架构/资深工程岗。

---

#### 0.3.2 各大中厂 AI 要求画像与技术栈侧重深度对比

通过对服务器 `jobs.db` 中各大中厂及独角兽岗位交叉对比，各家技术侧重点如下：

| 公司/阵营 | 应用侧样本 | 核心技术侧重 | 典型代表岗位与特征 |
|---|---|---|---|
| **字节跳动** | 334 (58.0%) | **RAG (44.9%) + 评测 (54.4%) + 并发分布式 + 多模态/视频**<br>语言 Go/Python/Java 均衡，C++（12.4%）用于安全风控与端侧 | **资深 AI Agent 工程师 (电商)**：要求深入 ReAct、Function Calling、RAG、上下文记忆、可观测与评测体系；<br>**CyberAgent 专家**：分析复杂 C/C++ 程序、代码执行轨迹、自动化评测；<br>**AI Native 全栈**：大前端跨端 + AI Coding 工作流构建。 |
| **阿里巴巴** | 47 (8.2%) | **Context Engineering (51.7%) + MCP (35.0%) + 沙箱隔离 (28.3%) + Harness (30.0%)**<br>Python (60.0%) + Java (43.3%) + Go (35.0%) | **智能引擎 Agent Infra / Aone Ground**：Linux/容器/Docker 调度，研发平台与 Coding Agent 基础设施；<br>**Token Foundry - Qwen Agent**：模型后训练微调、RLHF/PPO/DPO 与 Agent 决策实操；极度看重架构规范与协议标准化。 |
| **美团** | 47 (8.2%) | **评测闭环 (66.1%) + 上下文与记忆 (45.2%) + AI Coding (30.6%) + 成本控制 (25.8%)**<br>Java (41.9%) + Python (41.9%) + TS (27.4%) | **Agent 开发工程师 (基础研发平台)**：高可用分布式、MCP、ReAct、上下文与多级记忆、评测与观测；<br>**AI Agent Builder (无人机业务部)**：重度使用 Claude Code/Cursor 实践 AI Native 全栈研发，重构业务工作流。 |
| **腾讯** | 73 (12.7%) | **Agent Runtime 平台 + 可观测性 (22.2%) + 长任务状态机 (14.4%) + 沙箱 (15.6%)**<br>语言要求宽泛（工程底功），CSIG 腾讯云重度布局 | **Agent Runtime 平台产品/研发**：打造企业级 Agent 基础设施、SDK/CLI、运行时托管与计费体系；<br>**WorkBuddy 智能体客户端**：Electron + 全栈，桌面端系统性能治理与链路可观测。 |
| **网易** | 14 (2.4%) | **ReAct 规划 (58.8%) + RAG (52.9%) + MCP (41.2%) + AI Coding (41.2%)**<br>游戏与音乐垂直内容生产 | **游戏/内容 Agent 工程师**：大模型原理、ReAct 规划与工具调用落地、检验 Agent 产出结果；对跨系统 MCP 协议接受度极高。 |
| **百度** | 31 (5.4%) | **ReAct / CoT (47.5%) + RAG (33.9%) + 视频/创作多模态 + 沙箱 (11.9%)**<br>Python (25.4%) 主导 | **视频创作 Agent / 搜索 Agent 算法工程**：结合图像/视频多模态理解与 Agent 工作流编排，将学术成果快速工程落地。 |
| **AI 明星独角兽**<br>(DeepSeek/智谱/月之暗面/MiniMax) | 30 (5.2%) | **"Model + Harness = Agent" + 沙箱系统栈 + Code Agent + Post-training / RL**<br>Python (57.9%) + Go (47.4%) + Rust (31.6%)，RAG 趋近于 0% | **DeepSeek (DSec 弹性计算 / Harness 团队)**：托管成千上万沙箱，改造 OS/VM/网络存储调度；研发 Code Agent 数据与评估体系；<br>**智谱 (Harness 研发)**：主攻 Skills 生态、MCP 生态、Subagent 协作；<br>**月之暗面 (Kimi Code / Coding Agent)**：长任务丢目标治理、代码执行沙箱、OTel 遥测闭环。 |

---

#### 0.3.3 最新需要重点学习的技术栈清单

结合各大厂共识与前沿演进，2026 最新技术栈分为五大模块：

```
┌────────────────────────────────────────────────────────────────────────┐
│                      2026 企业级 AI Agent 技术栈全景                     │
├────────────────────────────────────────────────────────────────────────┤
│ 1. 编程语言与工程底座: Python (主力编排/Eval) + Go/Java (高性能调度) + TS (全栈UI)│
│ 2. 规划推理与执行循环: ReAct / Plan-and-Execute + Function Calling + 工具反思 │
│ 3. 协议规范与能力资产: MCP (Model Context Protocol) + Skills 封装 + 渐进式披露│
│ 4. 执行环境与安全边界: Docker / 微VM 沙箱隔离 + 权限三态 (ALLOW/DENY/ASK) + 审计│
│ 5. 信息装配与记忆系统: Context Engineering (预算/Manifest) + 多级记忆 (Memory) │
│ 6. 生产度量与质量闭环: 自动化评测 (LLM-as-a-Judge) + 结构化 Trace + 成本/时延控制│
│ 7. 新兴前沿工程范式: AI Coding (Claude Code/Cursor/TRAE) + 长任务 Checkpoint 容灾│
└────────────────────────────────────────────────────────────────────────┘
```

**与看板口径的差异**：看板页面（`https://xu.donglab.asia`）主张「主航道 = Harness + 长任务状态机 + 沙箱 + 上下文工程 + Trace→Eval」，那是**平台岗**口径（DeepSeek「Model + Harness = Agent」、月之暗面内核框架、智谱 Harness）。应用岗的差异是：

| 维度 | 平台岗（本计划不主攻） | 应用岗（本计划主攻） |
|---|---|---|
| Harness | 自己造调度层、状态机内核、沙箱 | 选型 + 配置 + 在业务约束下补齐 |
| 状态 | Event Log / Checkpoint / 跨副本恢复 | Task 状态语义、业务完成判定、幂等 |
| 沙箱 | 容器 vs gVisor/微VM、配额、成千沙箱 | 用现成沙箱，重点是权限与影响半径 |
| 上下文 | Working Set 预算、eviction 算法 | 什么信息该进上下文、按阶段装配 |
| Eval | 建 Eval 平台、回归门禁 | 建业务黄金集、Badcase 闭环、判断改动是否真有效 |
| 交付 | 平台能力、多租户、配额 | 业务流程接入、人机协作、上线与运营 |

但**看板里的 M1–M8 硬指标仍然全部保留**——它们是企业应用能不能上线的底线，只是实现深度不同（见 §6 验收基线）。基于最新数据，本计划补齐了 **M9 成本可归因**（成本 21.4%）与 **M10 Skill 可复用**（Skill 23.3%）两项。

---

## 1. 能力地图：企业 Agent 应用的 8 个能力域

来源：手册第 3 章 3.1.2 的"构建对象"表 + 第 2 章五层责任域，按应用侧裁剪。

| # | 能力域 | 核心问题 | 判断你是否掌握的标志 | JD 命中（应用侧 576 最新） |
|---|---|---|---|---|
| D1 | **业务与任务契约** | 这个 Agent 为谁工作、交付什么、什么算完成、哪些动作禁止 | 能写出可被业务方签字确认的 Agent Contract | 不可词频统计（需读全文判断） |
| D2 | **执行编排** | 任务怎么推进、何时等、何时委派、何时停 | 能画出状态机并解释每个终态的判定依据 | Harness 17.4% · Multi-Agent 19.3% · 长程 8.2% · Agent Runtime 6.1% · Loop 4.7% |
| D3 | **上下文与信息** | 每轮模型该看到什么、什么留在窗口外 | 能说明某次任务失败是"没看到"还是"看错了" | 上下文 28.0% · Memory 31.6% · Context Engineering 11.1% · 压缩 6.6% |
| D4 | **能力与行动** | 工具/Skill/MCP 怎么设计、怎么授权、怎么隔离 | 能讲清"模型知道工具"≠"有权执行" | AI Coding 24.1% · Skill 23.3% · MCP 20.8% · Function Call 11.1% · 沙箱 10.6% |
| D5 | **人机协作** | 何时必须人介入、怎么审批、断线怎么续 | 能设计出高风险动作的审批与回滚路径 | Human-in-the-loop 1.9%（低频、高门槛） |
| D6 | **治理与安全** | 提示注入、越权、数据出域、审计 | 能对一条攻击链给出分层拦截方案 | 权限 15.5% · 隔离 10.6% · 审计 6.6% · 注入 4.7% |
| D7 | **评估与调优** | 怎么证明变好了、失败怎么归因、怎么沉淀 | 能用同一批题对比两个版本并给出决策 | 评测 50.9% · 可观测 18.1% · Trace 6.2% · 评测集 6.4% |
| D8 | **规模化交付** | 多场景复用、版本管理、成本、上线运营 | 能说明第二、第三个 Agent 复用了什么 | 成本 21.4% · 高可用 15.8% · 延迟 13.0% · 灰度 4.9% |

**D1–D4 是硬技能，D5–D8 是决定"能不能上线"的分水岭**。多数自学者停在 D1–D4，做出 Demo 却进不了生产。

**新数据对这张图表的三个修正**：

1. **D7 评测（50.9%）已超半数，为断层第一工程信号。** 彻底推翻「先开发功能、后补评估」的自学路径。本计划坚决执行：W2 就必须开始积累第一批 trace 与验收题，W7 做体系化与回归门禁。
2. **D4 新增 AI Coding 与 Code Agent（24.1%）。** 大厂不仅要求工程落地，更要求以 AI-Native 方式（Claude Code / Cursor / TRAE）交付，并能构建代码辅助与自动化工作流。
3. **D5 的低频不代表可跳。** Human-in-the-loop 仅 1.9%，但凡是提到它的岗位，几乎都同时要求审批、回滚、审计链。这是「JD 写得少、面试问得深」的典型区，不能因为频次低就放到最后。

---

## 2. 12 周排期

每周结构固定：**读（手册对应章）+ 补（前一本书对应机制）+ 做（贯穿项目一个切片）+ 验（可演示产物 + 数字）**。

### 阶段 A · 建立企业视角（W1–W2）

#### 第 1 周：应用形态、架构坐标与任务契约

| 项 | 内容 |
|---|---|
| 手册精读 | 第 1 章（P14–19）应用形态演进与六个判定特征；第 2 章（P20–26）三视图 + 五责任域 + 五项设计原则 + Context/State/Memory/Knowledge/Skill 五类对象区分 |
| 手册略读 | 第 3 章（P29–42）四类构建入口——只需能说清"我选哪条路径、为什么、企业还要补什么责任" |
| 机制补充 | 《深入理解》第 1 章 P15–24：`Agent = LLM + 上下文 + 工具`、ReAct 循环 |
| 核心概念 | Workflow / Agent 主导 / Hybrid 的路径控制差异；Single / Long-Horizon / Multi-Agent 是形态而非构建方式；Chat → Copilot → Agent → Managed Agent 的演进 |
| 实践 | 选一个**真实企业业务场景**（建议：内部技术文档问答+工单处理，或客服退款，或运维告警初判）。产出 Agent Contract：角色、输入、交付物、成功标准、禁止动作、影响半径 |
| 验收 | ① 一页 Agent Contract，业务方视角能读懂；② 一张架构图，标出你的 Agent 落在五责任域的哪几格；③ 明确写出"哪些能力我复用现成产品，哪些我自己实现" |
| 失败练习 | 写一版"什么算完成"的模糊定义，然后找 3 个反例证明它不可验证，再改写 |

**本周要建立的判断力**：为什么企业不能照搬 Coding Agent 流程。手册 P29 明确：审批、交易、客服、运营任务有不同业务状态、权限边界和成功标准。

#### 第 2 周：任务循环与状态语义

| 项 | 内容 |
|---|---|
| 手册精读 | 第 4 章（P44–53）Agent Loop 五阶段、权威状态、Planning/Todo/阶段门禁、Subagent 委派、异步与长程续行、完成验证 |
| 机制补充 | 《深入理解》第 1 章 ReAct 轨迹 + 第 2 章 2.1–2.2（API 上下文结构、四种角色、带工具调用的多轮交互） |
| 核心概念 | Prepare→Model→Act→Observe→Verify；10 个任务状态（CREATED/RUNNING/WAITING_INPUT/WAITING_APPROVAL/WAITING_EVENT/PAUSED/VERIFYING/COMPLETED/FAILED/CANCELLED）；"WAITING 不是失败，PAUSED 不是结束"；预算作为外部终止边界 |
| 实践 | 实现贯穿项目的任务状态机：权威状态对象（goal/stage/facts/todos/artifacts/budgets/completion_evidence）+ 状态转移 + 预算约束。**Verify 阶段必须是环境事实校验，不接受模型自我声明** |
| 验收 | ① 状态转移图；② 一次任务能跑出 ≥10 步并落成结构化状态；③ 人为制造一次工具失败，展示失败分类与恢复路径；④ 展示一次"模型说完成了但 Verify 拦下"的案例 |
| 失败练习 | 让模型在没有 Verify 的情况下判断完成，统计假阳性率 |

**对齐看板指标**：M1 显式 Agent Loop（≥20 步）、M3 失败分类与恢复（≥3 种可配置路径）。

**本周补入的新增项（基于最新数据）**：

- **Day 1 就开始存 trace，不等 W6。** 评测已是应用侧第一大信号（36.9%），而 W7 才建评估集意味着前面 6 周的失败全部丢弃。本周只需做到：每次 run 落一份 JSON（steps/tools/errors/耗时），格式可以粗糙，但要能从 W2 起回放。
- **长任务容灾是本周的真实门槛，不是 W9。** JD 里长程只占 4.6%、状态机 1.2%、Checkpoint 1.1%，但面试与实战全压在这里。本周必须交出的不是「状态机图」，而是「杀进程后能续跑」的可执行证据。
- **`Agent Loop` 在 JD 里只占 4.7%，但 `Harness` 占 17.8%。** 面试时说「我实现了 Agent Loop」会被认为是基础能力；说「我把 Loop 的状态、预算、验证、恢复做成了可配置的 Harness 层」才是差异化。两种说法的工作量差在**失败分类与恢复策略是否可配置**。

### 阶段 B · 信息与能力（W3–W5）

#### 第 3 周：上下文工程

| 项 | 内容 |
|---|---|
| 手册精读 | 第 5 章 5.1–5.2（P54–57）Context 构建管线、System Context 动态编译六层、优先级六原则、预算分区、Context Manifest、Context Policy |
| 机制补充 | 《深入理解》第 2 章 2.3–2.5（KV/Prompt Cache、提示工程、Skills）+ 2.6–2.7（状态栏、分层压缩、子 Agent 隔离） |
| 核心概念 | **Context 是每次调用重建的视图，不是事实来源**；Manifest 七个字段（source_type/scope/version/trust_level/permission_basis/selected_reason/token_count/transform/content_hash）；压缩 vs 隔离；"隔离优于压缩" |
| 实践 | 为项目实现 Context 构建管线：按阶段装配不同内容；生成 Context Manifest；设 token 预算与淘汰策略；对比"全塞"与"按需装配"两版的任务成功率 |
| 验收 | ① Manifest 能回答"某条信息为什么进了这次调用"；② 两次改动可用同一批任务对比 token 与成功率；③ 能解释一次失败是信息缺失还是信息淹没 |
| 失败练习 | 故意把工具结果全文塞进上下文，观察关键约束被淹没后的行为漂移 |

**对齐看板指标**：M8 上下文预算（token/文件上限 + eviction 或摘要）。

**本周的新增要求（基于最新数据）**：

- **区分「装配」与「机制」两层。** 上下文 27.6% + Context Engineering 11.2% 说明岗位要你**会装配**；压缩 6.5%、KV Cache 1.2% 说明机制层是加分项。本周主线放在装配与 Manifest；压缩只做到「分层摘要 + 子 Agent 隔离」即可，**不要花时间实现 KV Cache 编辑**。
- **Skill 已反超 MCP（23.6% vs 20.7%）。** 本周必须把「动态提示词 / Skills」当成与上下文同等的一等公民：一个 Skill = 触发条件 + 输入输出契约 + 版本 + 失效规则，不是一段可复用的 prompt。
- **Memory 14.8% 高于多数机制词。** 要在本周明确区分三件事：Context（本次调用的视图）、State（任务权威状态）、Memory（跨任务沉淀）——它们的存储、生命周期、失效策略各不相同。

#### 第 4 周：工具、MCP 与能力设计

| 项 | 内容 |
|---|---|
| 手册精读 | 第 6 章 6.1–6.2（P64–67）Action Plane 完整链路、统一行动契约、Action Result 字段、Function Calling/MCP/A2A 职责边界、Tool 设计、Registry 与渐进式披露、Tool/MCP Server/Skill/Subagent/Remote Agent 边界 |
| 机制补充 | 《深入理解》第 4 章（P108–135）工具分类、粒度、描述、参数保真性、MCP、感知/执行/协作工具 |
| 核心概念 | **三个必须区分的事实**（P64）：模型看见工具 / Harness 注册工具 / 当前任务获得执行授权；"出现在 Tool Schema 中"≠"可以调用"；大结果外置；工具失败分类 |
| 实践 | 接入 ≥4 个工具，覆盖感知（只读检索）、执行（有副作用）、协作（委派子任务）三类；每个工具写清 schema 版本、参数校验、超时、结构化错误、结果截断规则；至少接 1 个真实 MCP Server |
| 验收 | ① 工具清单 + 权限矩阵；② 非法参数在到达执行逻辑前被拒；③ 一个工具的错误分类表（Tool/Model/Env/Budget 四类）；④ 能演示渐进式披露：注册 20 个能力但只向模型披露 5 个 |
| 失败练习 | 注入一个"描述含糊但实际危险"的工具，看模型会不会误用 |

**对齐看板指标**：M4 工具层契约（schema 有版本、非法参数被拒）。

**本周的新增要求（基于最新数据）**：

- **MCP 20.7% 是真实共识，但 A2A 只有 3.5%。** 本周把 MCP 做到能用（≥1 个真实 Server，含鉴权与版本），A2A 只做到「能说清与 MCP 的职责差异」，不实现。
- **Function Call 11.1% < MCP 20.7%。** 说明行业已默认「协议化接入」优于「函数写死在代码里」。工具不要写成 `def search()`，要写成有 schema 版本、可被外部注册的描述体。
- **Skill 与 Tool 的边界是本周最容易被问倒的点。** 用一句话区分：Tool 是模型可以**调用**的能力，Skill 是模型可以**遵循**的方法；前者有副作用与权限，后者是知识与流程的封装。

#### 第 5 周：受控行动、人机协作与安全

| 项 | 内容 |
|---|---|
| 手册精读 | 第 6 章 6.3–6.6（P67–75）Environment Contract、隔离工作区、Secret/网络/数据出站、Permission+HITL、Guardrail 与 Prompt Injection、Streaming/Channel/AG-UI、Trace 与效果闭环；第 14 章（P169–180）应用/模型/数据/身份/系统五层安全 |
| 机制补充 | 《深入理解》第 4 章 4.7（异步事件驱动）+ 第 2 章 2.4.7（提示注入） |
| 核心概念 | Policy Decision 三态 ALLOW/DENY/ASK；HITL 要放在"真正需要判断"的位置而非全流程；防护（盾）与管控（缰绳）双线；**"不被打穿"与"不越边界"是两件事** |
| 实践 | ① 工具在 Docker 内执行，默认无外网、有 CPU/内存/超时上限；② 高风险动作走审批：挂起→人工确认→恢复；③ 提示注入测试集 ≥8 条（直接注入、间接注入、工具结果污染）；④ 完整审计链：谁的身份、在哪个环境、依据什么策略、产生了什么副作用 |
| 验收 | ① 宿主机不被工具误伤；② 越权动作被拦截且留下可复核证据；③ 注入测试拦截率与误拦率；④ 演示一次"断线后从等待点恢复" |
| 失败练习 | 构造一条跨系统攻击链（网页内容 → 工具参数 → 数据外发），证明你的防线在哪一层被击穿 |

**对齐看板指标**：M5 最小沙箱执行、M6 结构化 Trace（每步输入/工具/参数/输出摘要/耗时/错误，按 run_id 可查）。

**本周的新增要求（基于最新数据）**：

- **沙箱 10.5%（字节 6.1% / 非字节 16.7%）是分化最大的信号之一。** 非字节样本（腾讯、阿里、网易）更看重沙箱，字节更看重 RAG。**无论投哪家，本周都要交出「默认无外网 + 资源上限 + 宿主机不被误伤」的实测证据**，这是唯一能用一句话证明的安全能力。
- **权限 15.5% 高于沙箱 10.5%，审计 6.5%。** 权限设计（谁能调用、在什么条件下、影响半径多大）比隔离技术更被需要。隔离是手段，权限才是目的。
- **Human-in-the-loop 仅 1.9%，但不要因此跳过。** 凡是提到它的岗位，几乎同时要求审批流、回滚、审计链。本周的 HITL 要做到「挂起 → 人工确认 → 恢复」全链路可演示，而不只是一个 `input()`。

### 阶段 C · 治理与运营（W6–W8）

#### 第 6 周：可观测性与可运营性

| 项 | 内容 |
|---|---|
| 手册精读 | 第 13 章（P146–168）AI 可观测性定义与边界、观测挑战、采集架构、高代码埋点、Agent 全链路观测模型与执行语义、错误/延迟/稳定性、Token 与成本、任务效果与输出质量、Agent 审计、AI 网关/推理引擎/沙箱观测 |
| 机制补充 | 《深入理解》第 6 章 6.8（Agent 可观测性） |
| 核心概念 | **"请求成功"≠"任务成功"**；动态执行路径难以还原；观测对象是 Agent/模型/工具/上下文/任务五个语义层；审计事实与业务 Evidence 的区别 |
| 实践 | 实现结构化 Trace：每个 run 有 run_id、每个 span 有阶段/工具/耗时/token/错误类；接入 OpenTelemetry 或等价结构化日志；做一个最小看板：成功率、工具错误率、平均轮次、P95 延迟、单位成功任务成本 |
| 验收 | ① 任取一条失败任务，只看 Trace 能定位到具体是哪一步、哪类错；② 成本能归因到任务而非只是总量；③ 审计链能回答"这次操作为什么被允许" |
| 失败练习 | 只保留最终答案、删掉中间 Trace，让同事排障，记录他多花了多久 |

**本周的新增要求（基于最新数据）**：

- **可观测 17.6% > Trace 6.3% > 评测集 6.3%。** 行业用「可观测」这个整体词，但真正落地时 Trace 是它的实现载体。本周产出应是「Trace 存储 + 查询 + 看板」三件套，而不是只打日志。
- **成本 20.9% 与 MCP 并列第二梯队。** 本周看板必须包含**单位成功任务成本**（而非总 token 消耗）。这是唯一能让「优化有效」变成可判断数字的指标。
- **延迟 9.7% 低于成本 20.9%。** 企业侧对成本的敏感度高于延迟，这决定了本周优化的优先级：先降 token 与调用轮次，再谈 P95。

#### 第 7 周：评估体系与黄金数据集

| 项 | 内容 |
|---|---|
| 手册精读 | 第 18 章（P233–235）数据飞轮总览；第 19 章（P236–239）轨迹数据阅读方法；第 21 章（P243–246）黄金数据集建设；第 22 章（P247–251）评估器与 Badcase 实验 |
| 机制补充 | 《深入理解》第 6 章（P167–194）评估环境、任务集设计、指标体系、LLM-as-Judge、配对比较、统计显著性、消融基础设施 |
| 核心概念 | 黄金集的"黄金"指题目与标准可信，**不是指答案漂亮**；评估器要写清满足/部分满足/不满足三级条件并要求给出扣分理由；确定性检查优先用 Code 规则，语义判断才用 LLM |
| 实践 | 建 ≥30 条业务任务评估集，覆盖正常/边界/异常/安全/长流程五类；每条有任务描述 + 完成标准 + 评分方式；至少 3 条"陷阱题"（看起来能做但应拒绝或应澄清）；建立基线并跑第一轮 |
| 验收 | ① 他人能按文档复跑你的评估；② 报告不只给平均分，还给失败数量与主要错误类型分布；③ 评估器与人工判断的一致率 |
| 失败练习 | 用同一批题分别让强模型和弱模型跑，检查你的评估集能否区分——不能区分就是题出了问题 |

**对齐看板指标**：M7 迷你 Eval（≥20 条固定任务，通过率/步数/工具错误率可对比）。

**本周的新增要求（基于最新数据）**：

- **本周是整份计划权重最高的地方。** 评测 36.9% 已是应用侧第一大工程信号，超过 RAG（36.7%）、Prompt（30.1%）、上下文（27.6%）。如果只能做好一件事，做这个。
- **从 W2 的 trace 里「回收」评估集，而不是新写。** 正确的做法是把 W2–W6 积攒的失败 trace 归类成题目，而不是坐下来凭空想 30 道题。这样题目天然带真实分布。
- **Benchmark 5.4% / 评测集 6.3% / LLM-as-a-Judge 1.2% 三个词的比例关系说明**：行业要的是「能建评测集」，不是「会用现成 benchmark」，也不是「会调 judge prompt」。评测集建设能力 > 评估方法选择能力 > 评估工具使用能力。

#### 第 8 周：调优闭环与能力沉淀

| 项 | 内容 |
|---|---|
| 手册精读 | 第 23 章（P252–256）受控自进化：经验库、Skill 沉淀、失败样本反哺 Harness；第 17 章 17.1（P213–217）判断优化对象是模型/Harness/执行环境；第 15 章 15.1–15.2（P181–184）Prompt 工程化与 Skill 版本发布 |
| 机制补充 | 《深入理解》第 8 章（P234–246）三种学习范式、从失败中学习、Skills 外部化、自我进化安全边界；第 7 章 7.5（何时 SFT、何时 RL） |
| 核心概念 | 优化对象判错会让所有投入白费：**工具协议含混、上下文缺失、权限失效、外部服务异常都不是模型问题**（手册 P213）；Skill 是版本化能力资产，需要验证、发布、回滚、失效检测 |
| 实践 | ① 从 Trace 里挑 5 条失败案例做归因分类，判断该改 Prompt/工具/上下文/Skill/Harness 还是模型；② 把一条验证有效的方法沉淀为 Skill（含触发条件、输入输出、版本、失效规则）；③ 做一次受控实验：改动前基线 vs 改动后，同批题对比，得出保留/回滚结论 |
| 验收 | ① 一份改动决策记录，含假设、变量、前后指标、结论；② Skill 在 ≥5 个同类任务中被正确触发或正确拒绝；③ 能说清"这个问题为什么不该用训练解决" |
| 失败练习 | 故意把该改工具的问题当成 Prompt 问题来调，记录浪费了多少轮 |

### 阶段 D · 规模化与交付（W9–W12）

#### 第 9 周：多 Agent 协作与何时不该拆

| 项 | 内容 |
|---|---|
| 手册精读 | 第 11 章（P122–132）从单 Agent 到团队、异构接入、组织拓扑（主管-执行/对等/分层）、任务分解分派聚合、团队共享上下文与最小充分共享、A2A/MCP 配合、团队治理 |
| 机制补充 | 《深入理解》第 10 章（P274–305）共享与隔离上下文、协作拓扑、并发冲突、错误级联 |
| 核心概念 | 协作收益 vs 协调成本；**"最小充分共享"而不是共享一切**；消息平面与协作状态分离；失败模式一：共享文件系统并发冲突；失败模式二：错误级联放大 |
| 实践 | 把贯穿项目拆成"执行 Agent + 独立验证 Agent"，保持同一评估集做单/多 Agent 对比；模拟并发写入、重复完成、上游错误三类故障 |
| 验收 | ① 单 vs 多 Agent 的成功率/质量/调用次数/延迟/成本并排表；② 有数据支撑的保留或回退决策；③ 任一子 Agent 失败不产生整体假成功 |
| 失败练习 | 拆出 4 个 Agent 后指标变差，定位是协调开销还是分工错误 |

#### 第 10 周：仿真验证与上线前质量门

| 项 | 内容 |
|---|---|
| 手册精读 | 第 16 章（P201–210）Agent Simulation：为什么需要、仿真边界（授权与后果，不是实现方式）、三种执行模式（全替身/混合/隔离真实依赖）、**被测系统不进仿真**、替换判断原则、数据契约与对象生命周期 |
| 机制补充 | 《深入理解》第 6 章 6.11（仿真环境：从评估到后训练的桥梁） |
| 核心概念 | 仿真边界只有两条：不触达未授权的生产账户/数据/网络、不产生不可控真实业务副作用；把工具调用顺序固定成脚本是最隐蔽的错误——被测的就不再是 Agent 的决策 |
| 实践 | ① 为项目搭一个仿真环境：模拟用户（会追问、会改主意）+ 模拟后台（会超时、会丢响应、会部分成功）；② 跑一轮上线前质量门：功能、异常、安全、成本四项；③ 出一份上线检查清单 |
| 验收 | ① 仿真能夜跑回归；② 明确标注哪类结论只在全替身模式成立、不能外推到真实依赖栈；③ 检查清单每一项有证据来源 |
| 失败练习 | 用全替身模式通过全部回归，再连隔离真实依赖跑一次，记录结论差异 |

#### 第 11 周：规模化交付与资产治理

| 项 | 内容 |
|---|---|
| 手册精读 | 第 15 章（P181–200）Prompt 工程化（模板/版本/评测/灰度/回滚）、Skill 验证与发布、MCP 管理、Agent Registry、资源发现（ARD/RAD）；第 3 章 3.6（P41–43）Agent Platform 能力边界；第 10 章（P113–121）异步任务、定时任务、工作流编排 |
| 机制补充 | 《深入理解》第 9 章（P248–273）多模态选一方向（语音/Computer Use/机器人）做架构认知 |
| 核心概念 | 能力资产从"单应用局部内容"变成"多 Agent 共同依赖的公共资源"时的治理跃迁；声明式依赖 vs 动态发现；内置调度 vs 外置调度的责任对比 |
| 实践 | ① 交付第二个业务 Agent，明确回答复用了哪些资产（Prompt 模板/Skill/工具/评估集）、新增了什么；② 为 Prompt 和 Skill 建版本与灰度发布流程；③ 接一个异步长任务场景（定时触发 + 事件驱动 + HITL 等待） |
| 验收 | ① 第二个 Agent 的开发时间相比第一个明显下降，且能归因到具体复用；② 一次 Prompt 变更能灰度、能回滚；③ 长任务在断连、重启、等待审批后都能继续 |
| 失败练习 | 让两个 Agent 共用一套 Prompt，观察改动引发的连带影响 |

#### 第 12 周：综合验收与结业交付

| 项 | 内容 |
|---|---|
| 手册精读 | 第 25–28 章（P268–356）实践篇选读 3 个与你的业务场景最近的案例（研发效能 / 设计工程 / 运维安全 / 客户销售运营）；第 30 章（P389–396）Agentic Application 到 Agentic OS 的五项结论、六类工程约束、自治阶梯、不可逆操作与补偿 |
| 核心概念 | 自治阶梯（从可靠执行到可控自治）；强制边界与观测边界；不可逆操作的补偿与撤销设计 |
| 实践 | 整合前 11 周成果，形成可演示、可测试、可复现的完整系统；写结业报告 |
| 验收 | 见 §6 结业验收清单 |

---

## 3. 贯穿项目

### 3.1 建议场景（三选一，按你实际能拿到数据的）

| 场景 | 优势 | 难点 | JD 支撑度 |
|---|---|---|---|
| **内部技术研究/文档 Agent** | 数据易得、无真实业务风险、可积累 | 业务价值说服力弱 | RAG 36.7% · 知识库 11.8% · Memory 14.8% |
| **客服工单处理 Agent** | 业务状态清晰、有审批与退款等高风险动作、贴近手册案例 | 需要构造仿真后台 | HITL 1.9%（稀缺但门槛高）· 权限 15.5% |
| **运维告警初判 Agent** | 长任务、多工具、需人机协作、可验证 | 需要造告警数据与处置环境 | 可观测 17.6% · 成本 20.9% · 高可用 15.6% |

> 三个场景在 JD 里都有真实岗位对应，没有明显优劣。**若目标是最大化投递匹配度，选「内部技术研究/文档 Agent」**——RAG（36.7%）与知识库（11.8%）是应用侧最高频的一类需求，且不需要仿真后台即可交付完整成果。

### 3.2 分阶段里程碑

| 里程碑 | 周 | 必须交付 | 对应 JD 信号 |
|---|---|---|---|
| M1 任务契约 | W1 | Agent Contract、架构图、构建路径选型说明 | 不可词频统计 |
| M2 可控执行 | W2 | 状态机、≥10 步任务、失败分类与恢复、Verify 拦下假完成、**首份 trace 落盘** | Harness 17.8% · Agent Runtime 5.6% |
| M3 信息与能力 | W3–W4 | Context 管线 + Manifest、≥4 个工具 + 权限矩阵 + MCP、**≥1 个可复用 Skill** | 上下文 27.6% · Skill 23.6% · MCP 20.7% |
| M4 受控与可运营 | W5–W6 | 沙箱隔离、HITL 审批、注入测试、结构化 Trace + **单位成功任务成本**看板 | 权限 15.5% · 沙箱 10.5% · 成本 20.9% |
| M5 可评估 | W7–W8 | ≥30 条黄金集、基线报告、一次受控实验、≥1 条 Skill 版本化 | 评测 36.9% · 评测集 6.3% |
| M6 可交付 | W9–W11 | 单/多 Agent 对比、仿真环境、第二个 Agent + 复用说明 | Multi-Agent 13.9% · A2A 3.5% · 灰度 4.9% |
| M7 结业 | W12 | 完整系统 + 演示 + 结业报告 | — |

**里程碑与旧版的三处调整**：

1. **M2 增加「首份 trace 落盘」。** 否则 M5 的评估集只能凭空造题，而真实岗位要的是「从生产轨迹回收评估集」的能力。
2. **M3 增加「≥1 个可复用 Skill」。** Skill 23.6% 已反超 MCP 20.7%，不能把 Skill 全部推给 W8。
3. **M4 明确「单位成功任务成本」。** 成本 20.9% 与 MCP 并列，仅报总 token 不算达标。

---

## 4. 每周执行节奏

每周 5 个学习单元，每个 2–3 小时：

| 单元 | 内容 | 产出 |
|---|---|---|
| 1 | 精读手册对应章节，标记概念与判断依据 | 章节结构图 + 疑问清单 |
| 2 | 读《深入理解》对应机制章节，补齐"为什么" | 300 字机制说明（能讲给非本专业的人） |
| 3 | 实现/让 AI 实现本周切片，自己审查架构与边界 | 可运行代码 + 架构决策记录 |
| 4 | 制造失败：改坏一个变量、注入一个错误、跑一次对照 | 失败轨迹 + 归因 |
| 5 | 填验收表、更新指标、写周复盘 | 周报 + Git 提交 |

**每周必须回答的 3 个问题**（写进周报，答不出就是没学会）：

1. 本周这个能力，如果去掉会以什么方式失败？
2. 我做了什么判断？依据是什么？如果判断错了会怎样？
3. 这周的数字和上周比，是变好还是变差？能不能归因到具体改动？

---

## 5. 考核方式

### 5.1 单周评分（100 分）

| 维度 | 分值 | 评价重点 |
|---|---:|---|
| 概念准确 | 20 | 能否用自己的话讲清本周核心概念，不背术语 |
| 架构判断 | 25 | 能否说清边界划分、失败模式、为什么这样选而不是那样 |
| 实践落地 | 30 | 是否真的跑起来，覆盖异常路径，不是只有 happy path |
| 数字证据 | 15 | 是否有可对比的指标，口径是否清楚 |
| 复盘质量 | 10 | 失败归因是否到根因，下一步动作是否具体 |

**硬性否决**（任一不满足，分数再高也不算通过）：

- 只有成功案例，没有失败分析
- 任务完成只依赖模型自我声明
- 工具没有参数校验、超时或错误处理
- 关键结论没有数字支撑
- 说不清某项设计为什么这样做

### 5.2 阶段检测

- **阶段 A 末（W2）**：闭卷 45 分钟——画出一次带工具调用的完整上下文结构；解释"缺历史消息"与"缺工具结果"的失败差异；为一个 50 轮任务设计状态与上下文方案。
- **阶段 B 末（W5）**：现场演示——构造一次越权尝试与一次提示注入，展示防线在哪层生效、哪层失效。
- **阶段 C 末（W8）**：给定一个 Agent 改动，完成假设→基线→改动→对比→决策的完整闭环。
- **阶段 D 末（W12）**：结业答辩。

---

## 6. 结业验收清单

### 6.1 能力域（对应 §1）

- [ ] D1 有业务方视角可读的 Agent Contract，完成标准可验证
- [ ] D2 状态机含 10 态语义，Verify 基于环境事实，有预算外部终止
- [ ] D3 有 Context 管线与 Manifest，能解释"某信息为什么进了这次调用"
- [ ] D4 ≥4 工具覆盖三类，schema 有版本，非法参数被拒，≥1 个真实 MCP
- [ ] D5 高风险动作有审批与恢复，断线可续
- [ ] D6 注入测试集 ≥8 条，越权被拦截并留证，沙箱隔离有效
- [ ] D7 黄金集 ≥30 条含 ≥3 陷阱题，有基线与至少一次受控实验
- [ ] D8 第二个 Agent 有明确复用归因，Prompt/Skill 有版本与灰度

### 6.2 看板 M1–M10 底线（应用侧口径）

| 指标 | 应用侧达标线 | 最新 JD 命中（576 最新） |
|---|---|---|
| M1 显式 Agent Loop | ≥20 步任务能跑通并收敛 | Loop 4.7% · Harness 17.4% · ReAct 10.6% |
| M2 Checkpoint/可恢复 | 进程中断后能从最近状态续跑 | 长程 8.2% · 状态机 12.1%（低频高门槛） |
| M3 失败分类与恢复 | Tool/Model/Env/Budget 四类，≥3 种恢复路径 | 无直接词频，属 Harness 子项 |
| M4 工具层契约 | schema 有版本，非法参数被拒 | MCP 20.8% · Function Call 11.1% |
| M5 最小沙箱 | Docker 内执行，CPU/内存/超时限制，默认无外网 | 沙箱 10.6% · 权限 15.5% · 审计 6.6% |
| M6 结构化 Trace | 每步输入/工具/参数/输出摘要/耗时/错误，按 run_id 可查 | 可观测 18.1% · Trace 6.2% |
| M7 迷你 Eval | ≥30 条（超出看板 20 条要求），含陷阱题 | 评测 50.9% · 评测集 6.4% |
| M8 上下文预算 | token/文件上限可配，有 eviction 或摘要 | 上下文 28.0% · 压缩 6.6% |
| **M9（新增）成本可归因** | 能算出单位成功任务成本，且能定位到具体阶段 | 成本 21.4% · 延迟 13.0% |
| **M10（新增）Skill 可复用** | ≥1 个 Skill 带触发条件/输入输出/版本/失效规则，在 ≥5 个任务中正确触发或拒绝 | Skill 23.3% · AI Coding 24.1% |

### 6.3 交付质量

- [ ] README 含安装、配置、运行、测试、评估方法
- [ ] 他人能在独立环境复现
- [ ] 无真实密钥/敏感数据进入代码、日志、报告
- [ ] 异常未被静默吞掉
- [ ] 无未说明的占位实现或跳过的测试

### 6.4 结业报告必备章节

1. 业务场景与 Agent Contract
2. 架构决策记录：每个"为什么这样选"，含被否决的方案
3. 能力域实现说明：D1–D8 各自怎么落地
4. 评估报告：基线、改动、对比、失败分类
5. 失败案例集：≥5 条，含根因与修复
6. 复用分析：第二个 Agent 复用了什么、省了多少
7. 局限与未解决问题（诚实列出）

---

## 7. 刻意不做的事

明确排除，避免精力分散：

| 不做 | 原因 | 最新数据校验 |
|---|---|---|
| 自研 Harness 调度内核 / 状态机引擎 | 应用侧用现成框架 + 补业务约束即可 | ✅ Harness 17.8% 但绝大多数要求「用/优化」而非「从零造」 |
| 自研沙箱隔离（gVisor / 微VM / 弹性计算） | 用 Docker 或现成沙箱服务，重点是权限设计不是隔离技术 | ✅ 沙箱 10.5% ≪ 权限 15.5%，隔离是手段不是目的 |
| 自研 AI 网关 / 多租户配额 / 流量治理 | 用现成网关，只需理解边界与语义 | ✅ 无对应高频词 |
| 大规模 SFT / RL 训练 | 只需能判断"该不该训"，手册第 17 章 17.1 的判据足够 | ⚠️ SFT 7.4%，但集中在算法/研究岗，应用侧仍需只做判断 |
| 追框架数量（LangChain/LlamaIndex/Dify/Coze 都试一遍） | 选 1 主框架 + 1 备用对照即可 | ✅ LangChain 13.5% + LangGraph 10.7% 已覆盖主需求；Dify/Coze 均 <3% |
| 无评估的 Prompt 调优 | 没有基线就没有改进 | ✅ 评测 36.9% > Prompt 30.1%，评估优先级高于 Prompt |
| 多模态深挖（语音/机器人） | 第 11 周做架构认知即可，除非业务明确需要 | ✅ 多模态 15.5% 但 VLM 3.6% · Computer Use 0.6% · GUI Agent 0.7%，深度岗稀少 |
| **实现 KV Cache 编辑 / 压缩算法**（新增） | 机制层是差异化加分项，不是准入门槛 | ✅ KV Cache 1.2% · 压缩 6.5% |
| **自己写 benchmark / judge prompt**（新增） | 行业要的是「能建评测集」不是「会用工具」 | ✅ 评测集 6.3% > LLM-as-a-Judge 1.2% |

---

## 8. 进度记录

| 周 | 阶段 | 主题 | 概念/20 | 架构/25 | 实践/30 | 数字/15 | 复盘/10 | 总分 | 结果 | 备注 |
|---|---|---|---:|---:|---:|---:|---:|---:|---|---|
| 1 | A | 应用形态与任务契约 | | | | | | | | |
| 2 | A | 任务循环与状态语义 | | | | | | | | |
| 3 | B | 上下文工程 | | | | | | | | |
| 4 | B | 工具、MCP 与能力设计 | | | | | | | | |
| 5 | B | 受控行动与安全 | | | | | | | | |
| 6 | C | 可观测性与可运营性 | | | | | | | | |
| 7 | C | 评估体系与黄金集 | | | | | | | | |
| 8 | C | 调优闭环与能力沉淀 | | | | | | | | |
| 9 | D | 多 Agent 协作 | | | | | | | | |
| 10 | D | 仿真验证与质量门 | | | | | | | | |
| 11 | D | 规模化交付与资产治理 | | | | | | | | |
| 12 | D | 综合验收 | | | | | | | | |

---

## 9. 手册阅读地图（按需查阅）

12 周计划只精读了部分章节。以下标注其余章节的用途，避免误以为没读就是漏了。

架构手册的现行正文在 [在线阅读站](https://aliyun.github.io/ai-agent-handbook/)（[仓库](https://github.com/aliyun/ai-agent-handbook)）。2026-10-19 的 396 页 PDF 已删除；下表页码只对应那一版快照，仓库之后仍有章节增补，查正文以阅读站章节为准。

| 章节 | 页码 | 本计划处理 | 何时回查 |
|---|---|---|---|
| 第 1–2 章 | 14–26 | **W1 精读** | 每次架构决策 |
| 第 3 章 | 29–43 | W1 略读 + W11 精读 3.6 | 选型、构建路径判断 |
| 第 4 章 | 44–53 | **W2 精读** | 状态机、委派、完成验证 |
| 第 5 章 | 54–63 | **W3 精读** | 上下文装配、Manifest |
| 第 6 章 | 64–75 | **W4–W5 精读** | 工具、权限、HITL、注入 |
| 第 7 章 | 78–86 | 选读 7.1 威胁模型 | 沙箱 10.5%，需能说清容器 vs gVisor/微VM 取舍 |
| 第 8 章 | 87–99 | 选读 8.1、8.4–8.5 | 需要设计状态存储或长期记忆时（Memory 14.8%） |
| 第 9 章 | 100–112 | 不读（Infra） | 除非要接自建网关 |
| 第 10 章 | 113–121 | W11 精读 | 异步任务、定时任务、工作流 |
| 第 11 章 | 122–132 | **W9 精读** | 多 Agent 判断与编排（Multi-Agent 13.9%） |
| 第 12 章 | 133–145 | 选读 12.2、12.4 | 需要设计通信契约时（A2A 3.5%） |
| 第 13 章 | 146–168 | **W6 精读** | Trace 与成本归因（可观测 17.6% · 成本 20.9%） |
| 第 14 章 | 169–180 | **W5 精读** | 安全分层设计（权限 15.5%） |
| 第 15 章 | 181–200 | W8 精读 15.1–15.2 + W11 精读 | 资产治理、版本发布（Skill 23.6% · 灰度 4.9%） |
| 第 16 章 | 201–210 | **W10 精读** | 仿真环境设计 |
| 第 17 章 | 213–232 | W8 精读 17.1 | 判断该不该训模型（SFT 7.4%，主要属算法岗） |
| 第 18–23 章 | 233–256 | **W7–W8 精读** | 数据飞轮全链路（评测 36.9%，全计划权重最高） |
| 第 24 章 | 257–265 | 不读（边缘部署） | 有全球化需求时 |
| 第 25–29 章 | 268–386 | W12 选读 3 个案例 | 找同类业务参考 |
| 第 30 章 | 389–396 | W12 精读 | 长期架构演进判断 |

**《深入理解 AI Agent》（306 页）** 作为机制查阅手册，页码已校对：

| 章节 | 页码 | 对应周 | 用途 |
|---|---|---|---|
| 第 1 章 AI Agent 入门 | 15–34 | W1–W2 | `Agent = LLM + 上下文 + 工具`、ReAct、Harness 工程（1.2） |
| 第 2 章 上下文工程 | 35–77 | W3 | KV Cache、提示工程、Skills（2.5）、状态栏（2.6）、分层压缩（2.7） |
| 第 3 章 用户记忆和知识库 | 78–107 | W3 | 记忆分层、RAG 与知识组织（Memory 14.8%） |
| 第 4 章 工具 | 108–135 | W4–W5 | 工具分类/粒度/参数保真性、MCP、异步事件驱动 |
| 第 5 章 Coding Agent | 136–166 | 按需 | 仅当业务涉及代码生成/仓库级上下文 |
| 第 6 章 Agent 的评估 | 167–194 | W7 | 评估环境、指标、LLM-as-Judge、统计显著性、可观测（6.8）、仿真（6.11） |
| 第 7 章 模型后训练 | 195–233 | W8 选读 7.5 | 只需能判断「何时 SFT、何时 RL」（P210–211） |
| 第 8 章 Agent 的自我进化 | 234–247 | W8 | 三种学习范式、从经验学习、Skills 外部化 |
| 第 9 章 多模态与实时交互 | 248–273 | W11 选读一方向 | 语音 / Computer Use / 机器人三选一（多模态 15.5% 但深度岗少） |
| 第 10 章 多 Agent 协作 | 274–305 | W9 | 共享与隔离上下文、协作拓扑、并发冲突、错误级联 |

---

## 10. 材料使用原则

材料只有本计划、[阿里手册在线阅读站](https://aliyun.github.io/ai-agent-handbook/)，以及本地《深入理解 AI Agent》PDF。不维护第二套大纲。机制细节回到原文查，理由：

- 二手笔记会丢上下文。手册的概念是成体系的（例如"三个必须区分的事实"依赖第 6 章 Action Plane 整条链路），摘出来就失真。
- 二次加工的笔记会与原文漂移。《深入理解 AI Agent》仍以本地 PDF 页码查证；阿里手册以阅读站章节为准，本计划里的手册页码只对应已删除的 2026-10-19 快照。
- 学习成果应沉淀为**可运行的代码和可对比的数字**（`code/`），而不是再写一份计划文档。

查机制时的定位方法：

| 想搞清楚 | 查哪里 | 最新数据依据 |
|---|---|---|
| 企业级架构与责任边界 | 手册第 2 章 P20–26 | 架构决策必查 |
| 任务循环、状态、完成验证 | 手册第 4 章 P44–53 | 长程 8.2% · 状态机 12.1% · Harness 17.4% |
| 上下文装配与压缩 | 手册第 5 章 P54–63 + 前书第 2 章 P35–77 | 上下文 28.0% · 压缩 6.6% |
| 工具、MCP、权限、HITL | 手册第 6 章 P64–75 + 前书第 4 章 P108–135 | MCP 20.8% · 权限 15.5% · HITL 1.9% |
| Trace、成本、审计 | 手册第 13 章 P146–168 | 可观测 18.1% · 成本 21.4% · 审计 6.6% |
| 评估、黄金集、Badcase | 手册第 18–23 章 P233–256 + 前书第 6 章 P167–194 | 评测 50.9%（第一硬指标） |
| 记忆、RAG、知识组织 | 前书第 3 章 P78–107 | RAG 36.5% · Memory 31.6% · 知识库 11.8% |
| ReAct、上下文缓存、压缩机制 | 前书第 1–2 章 P15–77 | ReAct 10.6% (宽口径42%) · KV Cache 1.2% |
| Skill 设计与能力资产化 | 前书第 2 章 2.5 P59–63 + 手册第 23 章 | Skill 23.3%（持续高频） |
| AI Coding / 工作流工程 | 手册第 1 章 + 前书第 4 章 | AI Coding 24.1%（最新跃升） |
| 多 Agent 协作与子智能体 | 手册第 11 章 P122–132 + 前书第 10 章 P274–305 | Multi-Agent 19.3% · A2A 3.5% |
| 仿真环境与沙箱执行 | 手册第 16 章 P201–210 + 前书 6.11 P191–192 | 沙箱 10.6%（独角兽/阿里重点） |

---

## 11. 数据流水线与维护指南

本计划的所有技能频次与招聘信号，均由部署在服务器 `xu`（`xu.donglab.asia` / `120.46.25.185`）上的 `ai_agent_hunter` 系统全自动每日定时监控与更新。

### 11.1 服务器端自动化全流程架构（Daily Pipeline）

整个系统实现了从数据抓取、去重比较、AI 研判、看板构建到 Web 发布的无人值守闭环：

```
[Linux Crontab (每天 08:30)]
           │
           ▼
[cron_runner.sh] ──启动主控调度，追加运行日志至 logs/cron.log
           │
           ├───────────────────────────────────────────────┐
           ▼                                               ▼
[1. 多渠道爬虫集群 (crawlers/)]                  [2. 状态 Diff 引擎 (storage.py)]
  - 字节跳动、腾讯、阿里巴巴、美团、百度、网易             - 计算 SHA-256(Title+Desc+Reqs)
  - Moka 渠道: DeepSeek, 智谱 AI, 月之暗面        - 对比 jobs.db (SQLite)
  - 飞书招聘渠道: MiniMax 等独角兽                - 产出: new(新增) / updated(变更) / unchanged
           │                                               │
           └───────────────────────┬───────────────────────┘
                                   ▼
             [3. 技能提取与报告生成 (analyzer.py)]
               - 正则词典提取 8 大类核心技术栈标签
               - 生成当日增量报告: reports/update_YYYY-MM-DD.md
               - 生成大模型研判输入包: reports/grok_input.txt (供LLM深度识别真假Agent与押题)
               - 输出当日增量 JSON: reports/latest.json
                                   │
                                   ▼
             [4. 看板聚合构建引擎 (web/scripts/build_dashboard.py)]
               - 对比前一日快照 data/prev_snapshot.json
               - 计算技能升降温: new(新出现) / risen(升温) / fallen(降温) / same
               - 硬核信号标记 (is_hardcore) 与噪声过滤 (is_noise)
               - 提炼本周焦点建议 (focus_signals: Harness, MCP, 沙箱, Eval, AI Coding等)
               - 生成 web/data/dashboard.json
                                   │
                                   ▼
             [5. 生产静态同步与发布]
               - 自动复制 dashboard.json 到 /var/www/ai-agent-learn/data/
               - 增量同步静态资源 /var/www/ai-agent-learn/assets/
                                   │
                                   ▼
             [6. Web 访问呈现 (Nginx: 80 → 301 → 443/TLS)]
               - 访问地址: https://xu.donglab.asia/#changes
               - 前端单页 (app.js) 实时消费 dashboard.json
               - 动态渲染「今日变更」、「技能气泡雷达」、「本周焦点」与「硬核岗位筛选」
```

### 11.2 监控看板核心功能（https://xu.donglab.asia/#changes）

1. **今日新增 / 变更视图（#changes）**：
   - **技能气泡（Skill Cloud）**：高亮展示当天较上一日新增（`badge-new`）或频次上升（`badge-up`，如 `+2`）的技术栈，点击可直观感知技术风向。
   - **建议本周焦点（Focus List）**：自动抓取排名前列的硬核技能（如 Harness, MCP, 沙箱, Eval, AI Coding, 长任务），指导当周重点突破。
   - **岗位详情与多维筛选**：支持一键切换「硬核信号」、「仅新增」、「隐藏噪声（过滤HR/运营/弱电等）」，直达大厂投递与 JD 原文链接。
2. **能力画像与学习自评（#portrait / #must / #phases）**：
   - 与本计划 D1–D8 及 M1–M10 验收基线联动，提供可在浏览器本地存储（LocalStorage）的掌握度勾选与自检。

### 11.3 本地复现与数据校准命令

平时无需在本地重复抓取，直接连接 `xu` 服务器执行查询或重跑统计：

```bash
# 1. 登录服务器查看当前岗位资产与最新更新
ssh xu "cd /root/ai_agent_hunter && python3 main.py stats"

# 2. 查看最近抓取日志
ssh xu "tail -n 60 /root/ai_agent_hunter/logs/cron.log"

# 3. 手动重新构建看板并发布（如果调整了技能词典或判定逻辑）
ssh xu "cd /root/ai_agent_hunter && python3 web/scripts/build_dashboard.py"

# 4. 导出最新全量数据到本地（如需做更深度的数据挖掘）
ssh xu 'cd /root/ai_agent_hunter && python3 -c "
import sqlite3, json
c = sqlite3.connect(\"data/jobs.db\"); c.row_factory = sqlite3.Row
rows = [dict(r) for r in c.execute(\"select company,title,location,recruit_type,description,requirements,source,publish_date,first_seen_at from jobs\")]
json.dump(rows, open(\"/tmp/jobs_export.json\",\"w\"), ensure_ascii=False)
"'
scp xu:/tmp/jobs_export.json /tmp/jobs_export.json
```

### 11.4 什么时候该调整学习计划

| 条件 | 动作 |
|---|---|
| 累计新增 ≥200 条 | 重跑频次统计，更新 0.3.1 技能总表 |
| 某核心信号占比变化 >5pp | 检查 8 大能力域（D1–D8）的权重与周次排期 |
| 出现全新工程范式（如 AI Coding 激增至 24%） | 在对应周次（如 W4/W5）补充针对性的工程实践任务 |
| 单日增量 <30 条 | 观察即可，依赖看板自动化展示，不随意改动主干计划 |

### 11.5 读数据时的关键陷阱

1. **语言词频不能直接当门槛。** Go 48.0% 里 60% 是「Go/Java/Python 至少一门」式并列；明确「Go 优先」只有 3.5%。遇到语言类高频词，必须回到原文看措辞形态。
2. **低频 ≠ 不重要。** 状态机 12.1%、Checkpoint、HITL 1.9% 虽属低频，但出现在 JD 里时几乎都是硬门槛。**高频词决定你学什么，低频词决定你能不能过面试。**