Agent 学习笔记（下篇三）：上线工程、进阶选择与操作界面（Stage 7 / 7.5 / 8 + 延伸路线）

学习来源 ：awesome-agentic-ai-zh ------ 一份把 Agent 从「模型基础」一路带到「上线工程」的中文学习地图。

本篇范围 ：Stage 7（Agent 上线工程）+ Stage 7.5（进阶 Agentic 选择）+ Stage 8（Browser Use / Computer Use / Sandbox）+ 五类角色延伸路线。

系列说明：Track B 构建者路线共三篇------下篇一（Stage 3--4）、下篇二（Stage 5--6）、下篇三（Stage 7 / 7.5 / 8 + 延伸路线）。三篇合起来才是完整的《下篇》。

本篇在系列里的位置

前两篇都在回答「怎么让它跑起来」。本篇换了一个更贵的问题：这东西能不能交给别人用？

• Stage 7 给出四件事：可测（Eval）、可看（Observability）、可停（Approval）、可恢复（Checkpoint / Resume / Recovery）。
• Stage 7.5 是 Stage 7 的「反过度设计」补丁：加复杂度之前，先拿证据证明它值得。
• Stage 8 决定 Agent 伸向外界的那只手伸多远：先 API，再浏览器，最后才是整台电脑；沙箱决定出错时能坏到哪里。
• 延伸路线 把同一套东西翻译成五类角色的日常动作：研究人员、开发者、教师、知识工作者、日常用户。

Stage 7 建安全网，7.5 防止网越织越贵，Stage 8 选最小的那扇门。

本篇四个部分的关系

	Stage 7	Stage 7.5	Stage 8	延伸路线
解决的问题	怎么证明它可靠	怎么避免过度设计	它能操作什么	不同角色怎么用
关键指标	Eval 分数、trace、恢复成功率	加上去的每一层是否仍值得	出错时能坏到哪里	你的日常流程是否变短
失败时的表现	「本地能跑，上线就出事」	堆了一堆 agent，效果没涨	误点、误发、越权	用了但没省时间

阅读建议

• Stage 7 是分水岭：前面在「让 Agent 能跑」，这里开始「让它敢交给别人用」。Eval 那一节的七字段建议直接抄成模板。
• 7.5 要反着读：它的每一节都在问「你确定要加这个吗」，读完请拿自己项目里最花哨的那一层对一遍。
• Stage 8 先选最小的门：有 API 就别开浏览器，有浏览器就别上整台电脑，这条顺序能省掉大部分风险。
• 延伸路线可以跳读：按你自己的角色挑一条，其余当参考。

目录

• Stage 7 ｜ Agent 上线工程：可测、可看、可停、可恢复
  • 7.1 核心词：一张表看清 19 个词
  • 7.2 Harness、Loop、Graph 与 Eval 怎么合作？
  • 7.3 Agent Harness：先把安全工作间准备好
  • 7.4 Agent Loop：做一步、看结果，再决定
  • 7.5 Workflow Graph：遇到岔路时知道往哪走
  • 7.6 Eval：先说要什么，再决定怎么评
  • 7.7 Observability：出错时看得见是哪一步
  • 7.8 Approval、Checkpoint、Resume 与 Recovery：先停，再安全继续
  • 7.9 完整上线路线：Eval → Observability → Approval／Recovery → Deploy
  • 7.10 OpenRouter、Pi、OpenCode、Orca、QM 到底有什么差别？
  • 7.11 Agent Benchmark Landscape：怎么看，不要只看排行榜
  • 7.12 要点回顾与复习索引
• Stage 7.5 ｜ 进阶 Agentic 选择：有证据才增加复杂度
  • 7.5.1 四个进阶做法的核心词
  • 7.5.2 先让另一个检查者照规则挑错
  • 7.5.3 故意弄坏一小块，确认系统会安全停下
  • 7.5.4 风险越高，Agent 能自己决定的范围越小
  • 7.5.5 模型变强后，重新证明每个外加步骤是否还值得
  • 7.5.6 其他模式：看到这种证据才选
  • 7.5.7 最小决策纪录：加之前先填完
  • 7.5.8 Model--Harness Fit：用 Eval 决定保留、简化或移除
  • 7.5.9 要点回顾与复习索引
• Stage 8 ｜ Agent 操作界面：Browser Use · Computer Use · Sandbox
  • 8.1 八个核心词：一条链上的不同位置
  • 8.2 先选最小的界面
  • 8.3 Sandbox：隔离技术、工作区与 Provider 怎么分
  • 8.4 四道安全检查
  • 8.5 选用现成工具的四条建议
  • 8.6 要点回顾与复习索引
• 延伸路线 ｜ 五类角色怎么用这套东西
  • 9.1 研究人员延伸路线（For Researchers）
  • 9.2 开发者延伸路线（For Developers）
  • 9.3 教师延伸路线（For Teachers / Educators）
  • 9.4 知识工作者延伸路线（For Knowledge Workers）
  • 9.5 日常用户延伸路线（For Everyday Users）
  • 9.6 要点回顾与复习索引
  • 本篇速查卡

Stage 7 ｜ Agent 上线工程：可测、可看、可停、可恢复

一句话导读 ：这一关把「能跑」变成「敢交给别人用」。顺序是固定的：先说清怎样算成功 → 留下做事纪录 → 危险动作先问人 → 确认跌倒后能继续 → 最后才交付。

先让 AI 帮手可测、可看、可停、可恢复，再交给别人使用。

让 Agent 可测、可看、可停、可恢复。这称为 Agent Production Engineering（Agent 上线工程）。像玩具车先装方向盘、刹车与仪表板；不需大规模。

全章用一个故事：AI 帮手查三个来源、整理摘要，送出前先请人确认。

先记住上线顺序：

先说清楚怎样算成功 → 留下做事纪录 → 危险动作先问人 → 确认跌倒后能继续 → 最后才交给别人使用。

你现在卡在哪里	先做什么	你要拿出的证据
不知道摘要算不算成功	先写固定案例与成功条件	可重跑的检查结果
出错时不知道坏在哪一步	记录每一步、错误、时间与成本	一次完整做事纪录
会寄信、付款、删除或写入数据	在动作前停下来问人，并先保存进度	谁同意了，以及要从哪里继续
前三项都能重跑并通过	才交给别人使用	系统是否正常、怎么停止、怎么回到旧版

先做稳单一 Agent；需要独立分工或互相检查时，再加 Agent。

• 做事纪录可能包含提示、工具输入与模型回答。不要把密码、个资或客户数据直接送进追踪平台。
• 多一个 Agent 通常就多一份模型调用、延迟与调试工作。不要假设多 Agent 一定比较快或比较准。

下面这张表是全章的骨架。19 个词被分成三组：先让任务跑得动 （Harness / Loop / Graph / 编排 / 多 Agent / Handoff）、再证明有做对 （Eval / Outcome / Trajectory / Grader / Trace / Observability）、最后让它能停能续（Guardrail / Human Approval / Checkpoint / Resume / Recovery / Idempotency）。

先看"五岁也能懂的说法"抓住方向，再看"本章用途／技术边界"了解这一关怎么使用它。同类词已经合并在同一组，不需要读两次。

7.1 核心词：一张表看清 19 个词

先解决什么	核心词	五岁也能懂的说法	本章用途／技术边界
先让任务跑得动	Agent Harness（Agent 执行架构）	AI 帮手工作的房间	放入模型、工具、权限、状态、错误处理与纪录的执行环境；本章用它安全地查资料与准备摘要
Agent Loop（Agent 循环）	做一步、看结果，再决定下一步	模型在一次任务里反复选动作、读取工具结果，直到完成、超出限制或需要问人
Workflow Graph（工作流程图）	有岔路的路线图	用步骤、连接、条件与状态排出不同情况该走的路；本章用它安排查数据、检查与送出前批准
Orchestration（编排）	安排谁先做、谁后做	控制步骤、数据流、角色、重试与停止条件
Multi-Agent（多 Agent）	几个 AI 帮手分工	多个 Agent 以清楚角色共同完成任务；它是选择，不是每套系统都需要
Handoff（交接）	把接力棒和笔记一起交出去	一个 Agent 把控制权、必要数据与成果证据交给另一个 Agent
再证明有做对	Evaluation／Eval（评测）	用同一张检查表反复检查	用固定案例、环境、评分方法与门槛量测 Agent 的结果和过程
Outcome（结果）	最后真的发生什么	任务结束时外部可验证的状态；本章要确认摘要真的包含三个合格来源，而不是只相信 Agent 说"完成了"
Trajectory（轨迹）	一路留下的脚印	一次运行中做过的事，包括工具调用、中间结果、错误与输出
Grader（评分器）	照规则批改一份答案	依成功条件为一个 Eval Case 评分的方法、程序或模型；本章要求保留规则与人工抽查
Evaluation Harness（评测执行架构）	固定出题、收卷和计分的考场	加载案例、重跑 Agent、调用 grader 并保存结果的测试系统；它和负责日常执行的 Agent Harness 不是同一个责任
Trace（追踪纪录）	把一路的脚印收进一本纪录簿	一次任务中依时间排列的步骤、工具调用、错误与结果；本章用它找出哪一步出错
Observability（可观测性）	替系统装透明窗	用追踪纪录、系统纪录与数值指标看见内部状态；本章用它找出摘要在哪一步漏掉来源
最后让它能停、能接着做	Guardrail（护栏）	先挡住不能做的事	限制输入、输出、工具权限或高风险操作的规则
Human Approval（人工批准）	危险动作先问人	运行敏感 tool call 前暂停，由人批准、修改或拒绝
Checkpoint（检查点）	先存盘再往下走	保存目前做到哪里和版本信息，让任务可以恢复
Resume（续跑）	回到存盘点继续	用同一个任务编号加载检查点并继续运行
Recovery（恢复）	跌倒后安全回来	失败后停止、重试、补偿或人工接手的策略
Idempotency（幂等）	按两次也只做一次	使用相同重试识别码时，不会重复寄信、付款或写入数据

**Prompt（提示）**是你交给模型的指令与材料。**Context（上下文）**是这一步需要看的数据。它们仍然重要；本章是在外面补上运行、检查和恢复的系统。

四个责任不是四代产品，也不是只能选一个。把同一个研究助理想成四个角度，就清楚了：

7.2 Harness、Loop、Graph 与 Eval 怎么合作？

它们不是四代产品，也不是只能选一个。请把同一个研究助理想成四个角度：

责任	白话问题	研究助理例子
Agent Harness	它在哪里安全做事？	只允许读数据；准备送出时必须停下
Agent Loop	它为什么再做一轮？	少一个来源就再查一次；达到上限就停止
Workflow Graph	遇到不同情况要往哪走？	来源不足就回去查；足够就进入人工批准
Eval	我怎么知道结果和过程合格？	检查三个来源、引用正确、没有跳过批准

Eval 会检查 Outcome 、Trajectory ，再由 Grader 依规则判断是否合格。Eval 可以让 Loop 重试、让 Graph 换路，或要求 Harness 停止；但把 Harness 和 Eval 放在一起，仍不会自动产生"何时重复、何时停止"的 Loop。

图 7-1　Harness、Loop、Graph 与 Eval 怎么合作：不是一个套一个，而是四个视角

7.3 Agent Harness：先把安全工作间准备好

模型像会想办法的大脑，但它不能自己读档、寄信或保存进度。Agent Harness 把工具和规则接在模型旁边，也常负责运行 Agent Loop。外层调度器可以多次调用同一个 Harness，所以 Harness 不只代表一次很短的运行。正式设计这个环境的工作常叫 Harness Engineering。

Harness 的 8 个核心组件

这八项是本项目的 production 检查表，不是全世界唯一的官方分类。

组件	五岁也能懂的说法	上线前要问
1. Orchestration／Run loop	决定下一步做什么	谁开始、谁停止、交接失败怎么办？
2. Tool／Permission boundary	只给它需要的钥匙	哪些工具能读、能写、能删？
3. Context／State／Checkpoint	保存它现在做到哪里	中断后能不能从正确位置继续？
4. Retry／Recovery／Idempotency	跌倒能重来，又不会重复扣款	重试会不会重复寄信、付款或写数据？
5. Guardrail／Human approval	危险动作先问大人	哪些操作一定要人按批准？
6. Telemetry／Observability	装上透明窗	能不能看到 trace、错误、延迟与 token？
7. Eval harness	每次改动都重新考试	有固定案例、评分规则和失败门槛吗？
8. Cost／Latency budget	先说可以花多少钱和时间	超过预算时要停止、降级还是排队？

回馈、恢复与成本的实作重点

• 工具错误要写成 Agent 看得懂的回馈，不只丢一大串 stack trace。
• 评分者最好和运行者分开；不要只问 Agent"你自己做得好不好"。
• 每个有外部副作用的动作都要设计 idempotency（幂等），避免重试时重复付款、寄信或添加数据。
• Prompt caching、batching、model routing 与较小模型都可能省成本，但效果依工作而异。先量 baseline，再改一项，再重测。
• Trace 可能收进敏感输入与输出。上线前设置遮罩、保留期限与访问权限。

7.4 Agent Loop：做一步、看结果，再决定

先分清三种很像、但范围不同的 Loop：

名称	它重复什么	例子
程序循环	同一段代码	for item in items；这是语法，不是本节主题
Agent Loop	模型 → 工具 → 工具结果 → 模型	一次 run 里持续调用工具，直到完成或碰到 max_turns
Loop Engineering	目标 → 动作 → 观察 → 调整	一次长 run 或跨 session／调度反复工作，每轮都有验证、记忆、预算与停止条件

IBM 用 Goal → Action → Observation → Adjustment 说明较外层的 Loop Engineering 。重点不是让 Agent 永远自己跑，而是每一轮都能回答：目标还成立吗？证据够了吗？要继续、停止，还是交给人？

因此，Loop Engineering 不是 Harness 的下一代产品，也不会自动淘汰 Harness。在 Anthropic 的用语里，Harness 本身就包含调用模型与路由工具的 loop；IBM 的 Loop Engineering 则把目标、检查、工具、hooks、context、subagent 与持久状态放进更大的反复工作设计。不同文档切边界的方法不同，所以请记责任，不要硬背一张唯一的层级图。

模型变强时，某个补丁可能可以删掉。例如 Anthropic 在较新模型上移除了先前 harness 使用的 context reset。但这只表示一个 workaround 经同一组 Eval 证明不再需要，不表示权限、安全、log、eval 或 recovery 自动过时。

7.5 Workflow Graph：遇到岔路时知道往哪走

Agent Loop 负责"要不要再做一次"。Workflow Graph 负责"接下来要去哪里"。它像一张有岔路的校园地图；地图能排路线，但不会替每一站完成工作。

外面的文章有时把这份工程工作称为 Graph Engineering。这是新兴称呼；真正需要学会的是 node、edge、branch、cycle、state、checkpoint 与 human approval，不是先背一个尚未统一的标签。

一个节点里可以有 Agent Loop；节点之间由 Workflow Graph 安排顺序。

什么时候选 Loop、Graph 或 Multi-Agent

• 任务只有一条路，但可能要重试很多次：先用 Loop。
• 任务有分支、平行步骤、人工批准或需要从中间恢复：用 Graph／Workflow。
• 不同部分真的能独立工作，或必须由不同角色互查：才加入 Multi-Agent。
• 一个 Graph 节点可以是 Agent、工具、固定程序或"等人批准"；不是每个格子都要放一个 Agent。
• max_concurrent_subagents 默认为 3，计算整棵树的活跃 subagent，不含 root。并行设置、总数与树深没有固定上限；分工可能增加 token。max_tool_calls 不支持。reasoning.summary 与 /responses/compact 也不支持。各 Agent 改用独立的 server-side 自动 compaction。
• Hosted collaboration 由 API 运行；自定义 function call 仍由应用程序运行。Context 分开不代表工具权限隔离；应用程序仍须批准敏感工具，并限制成本与停止条件。
• Google Managed Agents 的 Antigravity 是 Public Preview。antigravity-preview-09-2026 默认用 Gemini 3.8 Flash。提供托管 Linux sandbox 与跨 interaction 保留的文件。也有程序运行、自定义 function 与 remote MCP。
• 网络默认不限对外连接；先设 allowlist 与最小工具权限。搜索与 URL 获取不代表 GUI 浏览器控制；目前 computer_use 不支持。Sandbox 也不能取代本章的 Eval、批准与恢复。
• Google 文档说明：以 managed credential ID 引用秘密。Egress proxy 注入秘密，不暴露在 sandbox。Agent 能使用所提供 credential 的完整权限范围；只授予任务需要的最小范围。

7.6 Eval：先说要什么，再决定怎么评

Eval 不是一个分数，也不是等系统做完才补的报表。它先写清楚"怎样才算成功"，再用同一套方法检查不同版本。

先从 **Outcome（结果）**开始。研究助理的 Outcome 不是"Agent 说摘要完成了"，而是"摘要真的使用三个合格来源、引用可以打开，而且尚未跳过人工批准"。

接着创建完整的 Eval Case（评测案例）。它像一张连规则都写好的考题；input 只是其中一格。

Eval Case 的部分	研究助理例子	为什么要留
Input（输入）	整理这三个主题	告诉系统要做什么
Initial State（初始状态）	三个候选来源、尚未批准	固定开始时的环境
Success Criteria（成功条件）	三个来源都能打开；摘要包含可核对引用	说清楚怎样算成功
Forbidden Actions（禁止行为）	不得捏造来源；不得自行送出	即使答案漂亮也不能做的事
Optional Reference Answer（选用参考答案）	一份人工核对过的摘要	有需要时提供比较方向；不是每题都必须有
Grader（评分方法）	程序检查链接与数量，人检查摘要是否忠于来源	决定谁照什么规则评分
Case Metadata（案例信息）	case ID、版本、split、来源与标签	让同一题可以重跑和追踪

图 7-2　一个完整 Eval Case 的七个字段，以及 Eval Suite、Reviewed Eval Set 的层级

把多个完整案例放在一起，叫做 Eval Suite（评测组）。替 Suite 留下版本，才能知道这次和上次是不是在考同一份题目。

经人检查、可重复使用的完整案例集合，本项目称为 Reviewed Eval Set（已审查评测集） 。外部数据有时写 Golden Set 或 Reference Set，但这些名称没有跨供应商一致定义。看到它们时，要回到来源确认它是在说题目、答案、标准，还是整套数据。

**Golden／Reference Set 不只是 input，也不等于训练数据或 Few-shot 范例。**它通常包含完整案例、条件、参考证据与评分方法；实际字段仍要看当前项目的定义。

最后再加入这些测量词：

名词	白话意思	本章怎么用
Trial（试跑）	同一题实际做一次	模型结果会变动时，同一个 case 要跑多次
Baseline（基线）	改之前先量一次	提供新旧版本的比较起点
Regression（退步）	新版本超过预先门槛地变差	同时检查质量、成本、安全与可靠性
Development Set（开发集）	平常可以看的练习题	每次修改后重跑并用失败改善系统
Holdout Set（保留集）	平常不偷看的最后考卷	只在 release candidate 或最后验证时打开

工具可以不同，但每份报告都应留下 dataset version、split、case ID、trial 次数、grader、Outcome、Trajectory 与 baseline。

负责加载 cases、重跑 Agent、调用 grader 并保存结果的系统，是前面定义过的 Evaluation Harness。它可以调用 Agent Harness，但两者的责任不同：一个让工作安全运行，一个让测试可以重复比较。

7.7 Observability：出错时看得见是哪一步

Observability 像在透明积木盒外面看每一格。它不是把所有内容公开，而是留下能调试的 trace、log 与 metrics，并遮住密码、个资和客户数据。

在研究助理案例里，一次 **Trace（追踪纪录）**要能回答：查了哪些来源、哪个工具失败、重试几次、花了多少时间，以及为什么停在人工批准前。Trace 能解释 Trajectory，但"记录很多"不等于"结果正确"；Outcome 仍要交给 Eval 检查。

7.8 Approval、Checkpoint、Resume 与 Recovery：先停，再安全继续

研究助理准备送出摘要时，先进入 Human Approval。这不是请人从头重做，而是把摘要、来源与风险一起交给人核对。

批准前先保存 Checkpoint。重新启动后用 Resume 回到同一个 task；如果中间失败，Recovery 决定要重试、补偿、回到旧状态，或交给人。任何会寄信、付款或写数据的动作都要带 Idempotency key，确保相同重试只产生一次外部效果。

7.9 完整上线路线：Eval → Observability → Approval／Recovery → Deploy

**Deploy（部署）**是把通过检查的系统交给别人使用。它像开店前正式开门；开门不是成功证明，前面的测试、纪录、煞车和恢复方式才是。

这四步不是成熟度徽章，而是同一次修改要走完的检查路线：

顺序	先回答的问题	最少要留下的证据	没通过时怎么做
1. Eval	最后结果真的对吗？中间有没有走危险捷径？	Anthropic 建议先从 20--50 个代表真实工作的 cases 起步；这是实务起点，不是所有项目的硬性最低数。另记 Outcome、Trajectory、grader、成本与失败门槛	先补案例或修行为，不进部署
2. Observability	坏掉时找得到哪一步吗？	task ID、trace／span、tool call、错误类型、延迟、token 与敏感数据遮罩	先让失败看得见，再改 Prompt 或模型
3. Approval／Recovery	高风险动作能先停下吗？中断后能安全续跑吗？	人工批准点、版本化 checkpoint、resume 测试、idempotency key、拒绝／timeout／补偿路线	fail closed，停止自动运行并交给人
4. Deploy	前三项能在新版本重跑吗？	服务是否活着与准备好、用量限制、回到旧版的方法、停止开关与版本纪录	保留旧版或回到旧版，不把"服务有启动"当成功

Outcome Eval 要检查外部世界的结果。例如 Agent 说"信已寄出"只是文本；测试环境真的只有一封信、收件者正确，才是 Outcome 通过。Trajectory Eval 则检查它用了哪些工具、尝试几次、是否绕过批准、花多少 token。两种一起看，才不会只因最后一句很漂亮就放行。

案例先从真实失败创建：每遇到一次错误，就留下去识别化的输入、预期 Outcome、禁止动作与重现步骤。正式数据不能直接拷贝进公开 repo；必要时改成结构相同的假数据。

7.10 OpenRouter、Pi、OpenCode、Orca、QM 到底有什么差别？

它们不是五个同类产品。把它们放到正确层，就不会混在一起：

名称	它是什么	一句话记法
OpenRouter	模型 API 入口／Router	帮程序连接不同模型，本身不是帮你改程序的 Agent
Pi	Agent toolkit 和 coding-agent CLI	调用模型和工具，把任务做完
OpenCode	开源 coding agent	在代码项目里读取、修改、测试
Orca	多 Agent 开发环境	让多个 coding agent 在隔离 worktree 中并行工作和比较
QM	团队用的多 Agent harness	管理多人、workspace、权限、计划任务和协作

模型入口 → Agent runtime → 多 Agent 协作平台。这三层可以互相搭配，但不能互相代替。

让三个 Agent 一起辩论

先完成单一 Agent 的 Eval、安全执行与 Deploy 核心路线，再比较 Multi-Agent 是否真的更好。

• PRO / CON：同一题的赞成方与反对方。
• Judge：读完两边答案，再选出较符合题目与证据的一边。
• Output contract ：模型必须照约定格式回答。这题只接受 WINNER=PRO. 理由 或 WINNER=CON. 理由。

PRO 与 CON 都只看原题。Judge 才会看到原题和两份论点：

题目 ─┬─> PRO ─┐
      └─> CON ─┴─> Judge ─> WINNER + 理由

这只能提供第二个视角，不保证答案正确。医疗、法律或高风险决策仍要交给合格的人检查。

常见问题：

• 两边说得太像：把角色、要保护的目标与限制写得更明确。
• Judge 格式错误：保留错误并重试一次，不要默默选一边。
• 想减少顺序偏差：正式评测时交换 PRO／CON 显示顺序，再比较结果。

一边显示答案，一边确认 Cache

Streaming 让答案分段出现；Prompt caching让相同的长前缀有机会被重用。两者解决不同问题。

Streaming 与 Cache 是体验／成本技巧，不取代 Approval、Checkpoint 或 Recovery。

• Chunk：stream 里一次到达的一小段文字，不一定刚好是一个 token。
• First-token latency：从送出请求到第一段可显示文字的时间。
• Total latency：整份回答完成的时间。
• Cache breakpoint：告诉 API"前面这段可以重用"的位置。

何时值得 Cache、常见问题

适合：相同的长 system prompt、tool schema 或参考文件会在短时间内重复使用。

不适合：前缀每次都变、内容太短，或下一次调用通常超过 cache TTL。

常见问题：

• cache_control 放错段落：把 breakpoint 放在稳定前缀的结尾。
• 第二次改了前缀：空格、工具顺序或模型改变，都可能让它成为不同 cache。
• 只看理论折扣：同时把 write premium、read tokens、未命中与 output tokens 算进去。
• Streaming 中途断线：正式 UI 要标示未完成，不能把半份答案当成功。

7.11 Agent Benchmark Landscape：怎么看，不要只看排行榜

**Benchmark（基准测试）**像统一考卷。它能帮助比较，但不能保证你的真实工作也会一样好。

看任何分数前，先问五件事：

要看什么	大白话问题
Task	考题和我的工作像吗？
Environment	模型拿到哪些工具、数据和权限？
Grader	谁评分？规则有没有漏洞？
Trajectory	它真的完成任务，还是只碰巧拿到分数？
Hold-out	它有没有通过我自己没有拿来调整的测试？

**Reward hacking（奖励钻漏洞）**就是"拿到高分，却没有真的完成目的"。像小孩发现只要按一下铃就有糖，于是一直按铃，却没做原本的任务。

7.12 要点回顾与复习索引

• 上线顺序：Eval → Observability → Approval/Recovery → Deploy，四步不是徽章，是同一次修改要走完的路线。
• 四个责任分层：Harness（在哪安全做事）／Loop（为什么再来一轮）／Graph（遇到岔路往哪走）／Eval（怎么知道合格）。
• Harness 八个组件：编排、权限边界、状态与 checkpoint、重试与幂等、护栏与人工批准、遥测、评测、成本与延迟预算。
• Eval Case 七字段：input、initial state、success criteria、forbidden actions、reference answer（可选）、grader、metadata。
• Outcome vs Trajectory：一个看外部世界的真实结果，一个看它走了什么路径；两个都要测。
• Observability 要能回答：查了哪些来源、哪步失败、重试几次、为什么停在批准前。
• Approval 前先 Checkpoint，resume 用同一个 task id，有副作用的动作一律带 idempotency key。
• Streaming 与 Prompt caching 是体验／成本技巧，不替代批准、检查点与恢复。
• 看 benchmark 五问：Task、Environment、Grader、Trajectory、Hold-out；小心 reward hacking。

关键词	一句话记忆	常见坑
Eval Suite	一套可重跑的考卷	换题后直接对比分数
Golden Set	审过的完整案例集	把它当 input 或训练数据
Trace	一路的脚印	记录很多就以为正确
Checkpoint	游戏存档	没有 checkpointer 就谈恢复
Idempotency	按两次也只做一次	重试导致重复发信／扣款

Stage 7.5 ｜ 进阶 Agentic 选择：有证据才增加复杂度

一句话导读 ：这一关只有一个问题------哪个已重现的失败，值得你多加一层检查、故障测试、自主权分级或 Harness 元件？ 预设答案是「先不加」。

本章只回答一个问题：哪个已重现的失败，值得你多加一层检查、故障测试、自主权分级或 Harness 元件？

预设答案是"先不加"。先量单一 Agent 的 baseline；只有新做法在同一组 Eval 中带来可重现改善，才保留它。

7.5.1 四个进阶做法的核心词

先看白话总览，知道哪种问题才需要哪个词。表格下面的四段会再补上限制与来源，不把进阶概念缩成一句口号。

先处理什么	核心词	五岁也能懂的说法	何时使用／技术边界
先找出真正的问题	Evaluator--Optimizer／Agent-as-Judge（评估者---优化者／由 Agent 评分）	一个做，一个照清单检查	内容需要判断质量时才用；Judge 也会犯错，不能单独决定真相
Failure Injection／Chaos Eval（故障注入／混沌评测）	故意拔掉一块小积木，看房子会不会安全停下	只在隔离环境制造可控制的小故障；不能拿真实数据随意做实验
再控制新增的复杂度	Autonomy Gradients／Trust Layers（自主权梯度／信任层级）	事情越危险，AI 可以自己走的路越短	依风险缩小权限；付款、删除、发布或外部信息要先问人
Model--Harness Fit（模型---Harness 适配）	换了新引擎，就一次拿掉一个零件再重考	用同一组 Eval 决定元件要保留、简化或移除；安全责任不能因模型变强就删除

下面不是另一份名词清单；它只补充每个做法何时有用，以及最容易踩到的边界。

7.5.2 先让另一个检查者照规则挑错

Evaluator--Optimizer／Agent-as-Judge（评估者---优化者／由 Agent 评分）：一个角色产生成果，另一个角色按照明确 rubric 找出问题；产生者只在有新证据时做有界修正。

它适合"答案不只对或错，还要判断完整性、忠实度或写作质量"的任务。Judge 也会犯错，因此不能让它单独决定真相。至少搭配固定案例、可程序化检查、人工抽样与修正次数上限。

7.5.3 故意弄坏一小块，确认系统会安全停下

Failure Injection／Chaos Eval（故障注入／混沌评测）：主动制造可控制、可复原的小故障，例如 timeout、旧资料、坏格式或工具不可用，再检查停止、降级与复原是否符合预期。

"Failure Injection／Chaos Eval"是本章采用的编辑／社群统称，不是跨供应商公认标准名称。先在隔离环境测最小故障，不能随意在真实 production 资料上制造事故。

7.5.4 风险越高，Agent 能自己决定的范围越小

Autonomy Gradients／Trust Layers（自主权梯度／信任层级）：按任务风险分配不同程度的自主权。唯读查询可以自动执行；付款、删除、发布或外部讯息则先提出方案，再由人核准。

"Autonomy Gradients／Trust Layers"也是本章采用的编辑／社群统称，不是单一正式标准 。常见阶梯是 suggest → propose → execute，但实际层数由风险、权限与责任人决定，不由模型自评决定。

7.5.5 模型变强后，重新证明每个外加步骤是否还值得

Model--Harness Fit（模型---Harness 适配）：换模型或版本后，一次拿一个 Harness 元件做删除测试，用同一组质量、安全、成本与延迟 Eval 决定保留、简化或移除。

"Model--Harness Fit"是本章的编辑简称，不是公认标准术语。它不代表用模型取代权限、sandbox、audit log、人工核准或 rollback；这些是长期责任，不能因模型升级就直接删除。

这四种做法的共同前提是同一句话：先用单一 Agent 量出 baseline，再用同一组 Eval 证明新做法带来了可重现的改善。 没有证据时，加复杂度只会让系统更难测。

7.5.6 其他模式：看到这种证据才选

候选模式	白话说法	先看到什么证据
Parallel Exploration（平行探索）	同时试几条互不依赖的路，再比较	问题真的能分开，且增加的成本与合并工作小于质量或时间收益
Hierarchical Delegation（阶层式委派）	大工作逐层拆给较小角色	单一 context 放不下，或子任务有清楚输入、输出与验收人
Multi-Agent Handoff（多 Agent 交接）	把控制权、必要资料与完成证据一起交棒	不同角色必须直接接手，而且交接后的错误率低于单一 Agent baseline
Plan--Act--Reflect（规划---行动---回看）	先计划、执行、读证据，再有限次修正	测试或 grader 能指出可修正失败；不是只把同一句话再试一次
Dynamic Workflows（动态工作流程）	让 Agent 写出可重跑的分工 script	任务可平行、可重跑，而且固定 workflow 不足以表达当次分工

图 7.5-1　进阶 Agentic 选择：先有已重现的失败，再加一个做法

7.5.7 最小决策纪录：加之前先填完

已重现的失败：哪个 case 失败？Outcome 或 Trajectory 哪里不合格？
单一 Agent baseline：品质、成本、延迟、安全结果是多少？
只加的一个做法：它要防住哪个失败？
接受门槛：同一组 Eval 至少改善什么，而且不能牺牲什么？
停止／回复：没改善、变贵或变危险时，怎么撤掉？

如果第一行没有证据，先补 Eval case；如果第四、五行写不出来，先不要增加复杂度。

7.5.8 Model--Harness Fit：用 Eval 决定保留、简化或移除

模型变强时，某个重复提醒 prompt、context reset 或额外 planner／reviewer 可能不再需要。一次只改一个元件，其他 task、资料、工具、环境、grader 与门槛保持相同，再比较多次 trials。

图 7.5-2　Model--Harness Fit：一次只改一个元件，再跑同一组 Eval，决定保留、简化或移除

决定	你看到的证据	下一步
保留 Keep	拿掉后，同一个可重现失败又回来，或安全门槛退步	放回去，记下它防住的 case 与版本
简化 Simplify	保护仍有用，但较少步骤也能通过同一组 Eval	一次再少一个步骤，重跑相同 trials
移除 Remove	删除测试通过，质量与安全未退步，成本或延迟相同或更好	移除后持续监测，保留可验证的回复方法

先分哪一类	例子	判断边界
可能补某代模型弱点的元件	context reset、重复提醒 prompt、额外 planner／reviewer	模型变更时可以做删除测试，但只能由同一组 Eval 决定
长期安全责任	最小权限、sandbox、audit log、人工核准、rollback	实作可以更换；责任不能靠"模型变强"直接删除

7.5.9 要点回顾与复习索引

• 默认答案：先不加。只有「已重现的失败」才值得加一层。
• 四种做法：Agent-as-Judge（照 rubric 挑错）、Chaos Eval（故意弄坏一小块）、Autonomy Gradients（风险越高自主权越小）、Model--Harness Fit（换模型后逐个删元件重考）。
• 最小决策纪录五问：哪个 case 失败、baseline 多少、只加哪一个做法、接受门槛、怎么撤。
• Keep / Simplify / Remove 判据：拿掉后失败回来就保留；保护仍有用但步骤可减就简化；质量安全不退步就移除。
• 长期安全责任不能删：权限、sandbox、audit log、人工核准、rollback 不因模型变强而过时。

关键词	一句话记忆	常见坑
Agent-as-Judge	一个做、一个照清单查	让 judge 单独决定真相
Chaos Eval	先弄坏一小块看会不会停	在真实数据上做实验
Autonomy Gradient	越危险能自己走的路越短	由模型自评决定权限
Model--Harness Fit	一次只删一个元件	用「模型更强」删掉安全责任

Stage 8 ｜ Agent 操作界面：Browser Use · Computer Use · Sandbox

一句话导读 ：前面几关教 Agent「想什么、用什么工具」，这一关教它「从哪扇门做事」。门开得越大，能碰的东西越多------所以第一步不是找最强产品，而是选最小、最好检查的那扇门。

前面的 Stage 教 agent"想什么、调用什么工具"。这一关教另一件事：它要从哪一扇门做事。门选得越大，能碰的东西越多，风险也越大。所以第一步不是找最强产品，而是选最小、最好检查的门。

8.1 八个核心词：一条链上的不同位置

先把八个词认清。它们其实是一条链上的不同位置：看什么（Accessibility Tree）、怎么点（Browser/Computer Use）、在哪跑（Sandbox）、谁把关（Harness / Approval Gate）、防什么（Prompt Injection）。

Agent Interface（Agent 操作界面）

agent 用来看见、操作或执行工作的"门"。搜索、浏览器、桌面和隔离执行环境是大小不同的门。

Browser Use（浏览器操作）

工作全在网页里时使用。它可以读页面文字、按钮和表单，也能在需要时看画面与点击坐标。

Computer Use（电脑操作）

工作跨桌面 app 时使用。模型看截图并提出鼠标或键盘动作，真正执行的是你控制的程序。

Sandbox（沙箱）

把 code 关进独立工作房间。它只能看见你放进去的文件、网络和工具，出错时比较不容易伤到主机。

Accessibility Tree（无障碍树）

浏览器为辅助工具整理的页面地图，会标出文字、按钮、输入框和它们的状态。它不是原始 HTML 的全部内容。

Harness（执行框架）

包在模型外面的控制程序：接收动作、检查规则、真正执行、返回结果、限制轮数，并留下可查的记录。

Approval Gate（批准闸门）

像门口的刹车。付款、登录、发送消息、删除或其他难以恢复的动作前，一定停下来问人。

Prompt Injection（提示注入）

网页里的坏指令假装成任务内容，想骗 agent 忘记原本规则。页面文字要当成不可信输入，不是更高权限的命令。

8.2 先选最小的界面

你的任务	先用什么	小孩版理由
只找或读公开资料	Web Search／Fetch	只需要拿资料，不需要替你点击画面。
工作都在网页内	Browser Use	它看得懂按钮、字段和分页，门比整台电脑小。
工作跨桌面 app	Computer Use	只有这时才需要屏幕、鼠标和键盘。
要执行生成的 code 或改文件	Sandbox	先把程序放进隔离房间，再看结果。

正式 API 或 typed tool 优先。 如果服务已经提供清楚的 API，就先用 API；GUI 操作是必要时的 fallback，不是比较聪明的捷径。

图 8-1　先选最小的门：Search/Fetch、Browser Use、Computer Use、Sandbox

图的读法：先问任务真正需要什么，再选能完成工作的最小门。四张卡是四种选择，不是一定要按顺序升级。

基本 loop 是：

1. executor 截图。
2. 模型读图并返回一个或一批动作。
3. harness 检查 allowlist 和 approval。
4. executor 执行允许的动作。
5. 新截图与结果返回模型，直到完成或到达停止条件。

比较前先问四件事：

• 任务是不是同一批？ OSWorld 1 与 2.0 难度不同，不能直接把百分比相减。
• 完成怎么算？ binary completion 与 partial score 不是同一个分数。
• 给几步和多少 token？ budget 不同，结果就不能直接排在一起。
• executor 与环境一样吗？ model、tool batching、解析器和重试都会改变结果。

三种信号不要混成一件事：

信号	它提供什么	什么时候有用
DOM	网页程序的节点与属性	要读结构或使用 selector 时。
Accessibility Tree	对人有意义的角色、名称、状态	要找按钮、字段和可操作元素时。
Screenshot／pixel	画面真实的样子	canvas、图片、拖动或结构信号不够时。

与 scraping 的区别 ：scraping 主要取数据；Browser Use 还会交互。与传统 RPA 的区别：RPA 常走预先写好的固定步骤；agent 可以依页面状态选择下一步，但也因此更需要限制与验证。

8.3 Sandbox：隔离技术、工作区与 Provider 怎么分

词	白话意思	重要限制
Container	共用 host kernel 的隔离房间。	配置错误仍可能碰到 host 或网络。
Virtual Machine（VM）	有自己操作系统核心的房间。	通常比 container 重。
microVM	把 VM 做得更小、更快。	不是所有 sandbox 都使用 microVM。
Firecracker	AWS 开源的 microVM 技术。	技术名称不等于完整安全策略。
gVisor	在程序与 host kernel 中间多放一层用户空间 kernel。	兼容性与性能要实测。
Cold start	从没有环境到可以执行的等待时间。	受 image、区域与测量方法影响，不存在固定冠军。
Workspace	agent 在这次工作能看见的文件空间。	只放任务需要的文件。
Session	仍然存活、可以继续工作的 sandbox 实例。	与聊天记忆不是一件事。
Snapshot	保存某个工作区状态，以后从那里再开。	秘密与临时文件也要先清掉。

8.4 四道安全检查

检查	动手前先问
1. Isolate（隔离）	它在新 browser profile、container 或 VM 里吗？
2. Allowlist（白名单）	只允许哪些网站、文件、工具和动作？
3. Approve（批准）	哪些动作一定要停下来问人？
4. Verify & Log（验证与记录）	做完怎样看证据？失败时能追到哪一步？

图 8-2　Agent 动手前后的四道检查：隔离、限制、先问、验证与记录

四道检查要一起设计，但不是固定的嵌套技术层。每一次 action 都可能被其中一项或多项挡下。

8.5 选用现成工具的四条建议

• 只要摘要或找资料：先用产品内置 search／fetch，不要开启自动操作。
• 任务只在网站：使用有 domain allowlist、操作预览与确认步骤的 Browser Use。
• 跨 app：把 Computer Use 放在专用 profile／VM，先用测试数据。
• 长任务：先写停止条件与完成证据；background 不等于可以不检查。

8.6 要点回顾与复习索引

• 四扇门由小到大：Search/Fetch → Browser Use → Computer Use → Sandbox；正式 API 优先，GUI 是 fallback。
• 基本 loop 五步：截图 → 模型给动作 → harness 检查 allowlist 与 approval → 执行 → 新截图回传。
• 三种信号别混：DOM（结构）、Accessibility Tree（可操作元素）、Screenshot（真实画面）。
• Sandbox 词族：container / VM / microVM / gVisor；还要管 workspace、session、snapshot。
• 四道检查：Isolate、Allowlist、Approve、Verify & Log------要一起设计，不是固定嵌套。
• Prompt Injection 的底线：页面文字是不可信输入，不能当更高权限的指令。
• 比较 GUI agent 前先问四件事：任务是否同批、完成怎么算、给多少步与 token、executor 与环境是否一致。

关键词	一句话记忆	常见坑
Browser Use	只在网页里做事	当成万能爬虫
Computer Use	跨桌面 app 才用	在主机默认环境里跑
Sandbox	隔离的房间	把 container 当绝对安全
Approval Gate	门口的刹车	只在最后一步才问人
Prompt Injection	网页里的坏指令	把页面文字当系统指令

延伸路线 ｜ 五类角色怎么用这套东西

一句话导读：同一个 Agent，在不同角色手里长出完全不同的用法。这一章把官方给的五条延伸路线并排放在一起，方便你按自己的场景取用。

9.1 研究人员延伸路线（For Researchers）

让AI帮你找到资料、看懂资料，再确认答案确实有资料支持

• Source（来源）：用来查证的原始材料，如 paper、数据集或研究记录。
• Claim（主张）：可检查的说法，例如"方法 A 在数据集 B 上更好"。
• Citation（引用）：带你回到来源位置的路标，不保证来源真的支持主张。
• Source Verification（来源核对）：打开原文，检查内容、范围与限制是否和答案一致。
• Literature RAG（文献 RAG）：先从获准使用的文献找片段，再交给模型回答。
• Reproducibility（可重复性）：别人拿到数据、步骤、版本与设置后，可以重新跑出可比较结果。
• Private Data（私人资料）：不能任意公开或上传的内容，如受试者数据、病历、未公开手稿和公司机密。
• Human Review（人工审查）：由人对 claim、citation、代码、表格和最终决定负责；AI 不能替你签名或承担责任。

核对一篇 paper 的三个答案

上传前先确认许可或版权 与工具条款都允许。paper 公开可读，不代表可以交给另一个服务。

使用公开 paper：Attention Is All You Need。把 paper 加到能显示 citation 的工具，再复制：

请只根据这篇 paper 回答下面三题。每个答案都要附 citation；找不到证据就写"unsupported／未支持"，不要猜。
1. 这篇 paper 想解决什么问题？
2. 作者提出的方法包含哪些主要部分？
3. 作者用哪些实验支持结果，又说了哪些限制？
回答后，列出每个 citation 对应的 original text。不要把你的推测写成作者的 claim。

点开每个 citation，把答案和 original text 放在一起读；原文不支持的句子标成 unsupported／未支持，不要硬补不相干的引用。

把单篇练习变成可重跑研究流程

文献 inbox

保存 DOI、URL、作者、年份与取得日期；让工具生成摘要但把每个 claim 连回原文；由人工决定"阅读、排除、待确认"并记录理由。

跨 paper synthesis

先问每篇 paper 各自说什么，再比较同意、冲突和不同条件。不要先要求模型写完整故事，再回头找引用。

代码与实验

保存数据版本、environment、seed、prompt、模型／工具版本、输出与人工修改。能重新执行不代表结论正确，但没有记录更难找到错误。

投稿前

逐一核对 claim、citation、表格、图、代码与期刊规范；作者仍须最后判断并按期刊政策披露 AI 使用。

常见错误、替代方案与排错

问题	先怎么做
citation 不支持答案	标为未支持，缩小问题，不要硬补相关引用
工具读不到扫描 PDF	先做 OCR，再抽查页码与公式
多篇 paper 结论混在一起	要求每个 claim 列 paper 名称、页码或段落，再 synthesis
数据不能上传云端	使用机构核准环境；必要时看 Stage 6 的本机 RAG 路线
自动化太复杂	回到"一篇 paper、三个问题、逐条核对"

没有工具能代替 IRB、数据治理、作者责任或领域专家判断。

9.2 开发者延伸路线（For Developers）

AI 编程助手像一个会读文件、改代码、运行命令的队友。它速度快，也可能出错。这条路教你先缩小任务，再看懂每项改动，最后由人决定是否保留。

• IDE／Surface（集成开发环境／操作界面）：IDE 是写代码的工作台；Surface 是操作工具的入口，例如 CLI、IDE、desktop 或 cloud。同一工具可以有多个 Surface，看起来像 IDE 不代表它只能在 IDE 中工作。
• Coding Agent／Harness（程序代理／代理运行框架）：Coding Agent 会读代码、使用工具、修改文件并根据结果继续。Harness 把模型、工具、规则与执行循环连接起来。两者常在同一产品中，但含义不同。
• Provider／Router（供应商／路由器）：Provider 提供模型服务；Router 把请求发送给一个或多个 Provider。Router 不是模型，也不会管理 repo 权限。
• Model／Runtime（模型／运行环境）：Model 生成下一步内容；Runtime 让模型在本机或服务中运行。本地 Runtime 不等于会改代码的代理。
• Sandbox（沙箱）：运行代码的有限区域，能缩小出错范围，但不是百分之百的保证。
• Approval（人工批准）：高风险操作前由人明确许可。Test 通过不等于自动获得 push、merge 或 deploy 权限。
• Diff／Rollback（差异／回滚）：Diff 显示改了什么；Rollback 撤回不想要的改动。先读 Diff，才知道回滚应触及哪些文件。
• Eval／Observability（评测／可观测性）：Eval 用固定案例测质量；Observability 保存执行中的 trace、log、成本与错误。

不要混淆 OpenCode、Pi、OpenRouter 与 Ollama

名称	核心身份	白话说法
OpenCode	Coding Agent／Harness	在代码项目中读取、修改并测试
Pi	Coding Agent／Harness	从小核心加入 extensions、skills 或 RPC
OpenRouter	API Router	把模型请求发送给 Provider；不会修改 repo
Ollama	Local Model Runtime	在本机运行模型和 API；本身不是 Coding Agent

OpenCode／Pi 负责做事，OpenRouter 负责带路，Ollama 负责运行本地模型。

完成一次可回滚的小改

请在可丢弃的 demo repo 或新 branch 操作，把下面内容贴给 Coding Agent：

先做 read-only plan，不要修改任何文件。
任务：找出 README.md 中一句可以更清楚、但不改变技术含义的句子。
请先回报要改哪一句、为什么是小范围改动、应运行哪个 test 或文档检查，以及 rollback 方法。
在我明确人工 Approval 前不要写文件。批准后只准修改 README.md。
完成后显示 git diff -- README.md，并回报 Test 结果。不要 push、merge 或 deploy。

读完 plan 后由人工批准。修改完成后运行：

git diff -- README.md
# 接着运行这个 repo 的文档 test 或最小相关 test

若改动不对，确认 README.md 没有别人的工作后，只回滚本练习的改动；不要清空整个工作区。

从每日小改走到团队 workflow

每日开发

plan → 人工批准 → 小改 → diff → test → review → commit。每一步都应能停下。

PR review

把代理意见当作候选 finding；要求文件、行为、复现方式与建议 Test。没有证据的猜测不能直接阻挡。

CI

CI agent 使用只读 token、最小 repo 权限与固定输入。Issue、PR 或网页文字不能直接变成可执行命令。发布、merge 与 secrets 保留额外批准。

批量重构

先建立基准测试，再按模块分批。每批都有 checkpoint、Diff 与 Rollback；不要一次交出整个 repo。

常见错误、替代方案与 rollback

问题	改成什么
看到 IDE 画面就以为工具只能在 IDE 用	分开看核心身份与所有 Surface
把 OpenRouter、Ollama、OpenCode 当同一类	Router、Runtime、Coding Agent 分开选
工具说 Test 绿就直接接受	自己读 Diff、确认覆盖需求，再人工批准
用固定行数判断安全	看范围、可测性、可回滚性与 Diff 是否可读
Aider 自动 commit 就跳过 hook	启用 repo 所需的 verify／hook，再走正常 review gate
多个工具同时改同一文件	分清 ownership，使用独立 worktree，最后人工整合

Rollback 前先看 git status 和 Diff，只回滚已确认的目标，不用 broad reset 清掉别人的工作。

9.3 教师延伸路线（For Teachers / Educators）

AI 可以先做草稿，教师负责决定能不能用。这条路教你用 AI 准备教材、设计练习与整理反馈，同时保护学生数据，不把判断交给机器。

教师把关循环

• Learning Objective（学习目标）：这堂课结束时，学生应该能做出的具体行为，例如"能用自己的话解释水循环"。
• Scaffolding（脚手架）：先给提示、范例或步骤，等学生会做后再慢慢拿掉，像学骑车时的辅助轮。
• Rubric（评分规则）：先写出可观察的判准，让教师和学生知道作品会怎样被看。Rubric 可以请 AI 草拟，但要由教师定稿。
• Formative Assessment（形成性评估）：学习途中做的小检查，用来决定下一步怎么教，不是只在最后给一个分数。
• AI Literacy（AI 素养）：知道 AI 能做什么、会错在哪里，并能负责任地使用和说明它。
• Student Data（学生数据）：能直接或间接认出学生的数据，例如姓名、学号、作品、成绩、声音或行为记录。
• Human Review（人工审查）：人真的读过输出、核对来源并做决定，不是只按一下"接受"。
• Academic Integrity（学术诚信）：清楚说明哪些协助可以用、哪些必须自己完成，以及何时要披露或引用 AI。

先守住五条安全线

1. 先看校方政策：学校规则、核准工具与家长／学生通知要求，比这份学习地图优先。
2. 不要放学生数据：练习先用虚构内容。未经校方核准，不把姓名、作品、成绩或可识别记录贴进工具。
3. 教师保留决定权：AI 可以草拟反馈与 Rubric；成绩、纪律、升学或特殊教育等重大决定由合格人员负责。
4. 每次都要 Human Review：核对事实、引用、偏见、年龄适切性、无障碍需求与课程目标。
5. 把使用规则说清楚：让学生知道什么可以用、如何披露，以及哪些学习证据必须自己完成。

图 9-1　教师把关循环：AI 只做草稿，教师检查与决定

9.4 知识工作者延伸路线（For Knowledge Workers）

把散乱的会议记录、Email、文件与待办，整理成"看得懂、找得到、有人负责"的工作成果。AI 可以帮你先整理；来源、权限与最终决定仍由人负责。

常见工作包括：Email 分流、会议转行动项目、每周报告、产品需求整理、研究摘要与知识库整理。

• Source（来源）：原始 Email、逐字稿、文件或数据列，答案要能指回它。
• Action Item（行动项目）：有人要完成的一件事，写清做什么、谁负责、何时完成。
• Knowledge Base（知识库）：把可复用资料放在固定地方，让人和工具找得到。
• Private Data（私人数据）：公司、客户、员工或个人数据；没有政策和权限前不要交给新工具。
• Human Review（人工审查）：人对照 Source，检查内容、语气、收件人和缺漏，再决定能否使用。
• App／Connector（服务内连接器）：AI 服务连接 Gmail、Drive、Slack 等来源的桥。ChatGPT 已把 Connector 改称 App；其他服务仍可能使用 Connector。
• MCP Server（MCP 服务器）：按 MCP 规范把数据或工具交给兼容 client 的服务，不是 ChatGPT App，也不代表公司已核准。
• Workflow Automation（工作流自动化）：看到 trigger 后按固定步骤执行 action。
• Approval Gate（人工核准关卡）：流程暂停，等人确认后才寄信、发帖、改数据或删除内容。

三者不要混在一起：App／Connector 是服务里的桥；MCP Server 是协议端点；Workflow Automation 是会反复执行 trigger、条件与 action 的流程。 同一产品可以同时包含它们，但名称不能互换。

你的需求	先用什么	何时升级
偶尔整理公开或已核准的文字	一次性聊天	同一件事开始反复做时
从公司 Gmail、Drive、Slack 或 Microsoft 365 找来源	组织核准的 App／Connector	现成连接器做不到且管理员同意自定义连接时
每次新 Email／表单都跑相同步骤	Workflow Automation	测试数据跑通后加入 Approval Gate

进阶办公流程与产品经理用法

工作	安全的第一版	之后再自动化
Email 分流	去标识测试信，只生成分类与回信草稿	管理员核准 inbox；寄出前保留 Approval Gate
会议 → Action Item	逐字稿生成可回查 Source sentence 的表格	写入 task 系统前确认 Owner 与 Due date
Weekly report	人工提供核准指标	保留来源链接与发送前审查
产品需求	将虚构 feedback 分成问题、证据、假设、下一步	连接工单前限制项目、字段与 action
Knowledge Base	先对少量文件做分类草稿	批量改标签前备份并抽查

替代方案与排错

• 找不到资料：先确认能否直接打开 Source，再查账号、日期、同步与管理员设置。
• 重复建任务：检查 action 是否再次触发自身，加入唯一 ID 或去重条件。
• AI 补猜 Owner／Due date：要求每行附 Source sentence，缺资料就填 Needs confirmation。
• 不确定要不要 MCP：先用服务内 App／Connector。
• 自托管太重：先用组织核准的云服务；自托管不是隐私捷径。

四条路线放在一起看，共性只有三条：AI 做草稿、人做决定、来源要能指回去。 剩下的是场景差异------研究者怕引用不实，开发者怕改坏代码，教师怕泄露学生数据，知识工作者怕发错人。

9.5 日常用户延伸路线（For Everyday Users）

把 AI 当成"先帮忙写草稿的助手"。你先给它材料和要求，它先做一版；最后仍由你对照原文、修正并决定要不要使用。

• Prompt（提示）：你交给 AI 的要求。像写一张工作小纸条，要说要做什么、可以用什么材料、结果长什么样。
• Source（来源）：你要 AI 依照的原文、图片或材料。最后要回来对照它，不能只相信 AI 的记忆。
• Private Data（私人数据）：不该随便交给别人的数据，例如密码、身份证号、未公开公司文件或他人的个人信息。
• Hallucination（幻觉）：AI 不知道答案时，仍可能写出一段很像真的内容。句子好看不代表事实存在。
• Human Review（人工审查）：由人把草稿和 Source 一项一项比对，修正后才决定是否使用。
• App／Connector（服务连接器）：聊天服务通往 Gmail、Drive 或其他服务的一扇门。它能做什么，取决于产品和你给的权限。
• CLI Agent（命令行 Agent）：在终端里工作的助手。它可能读写文件或执行命令，所以动手前要先看计划与 diff。
• Local LLM／Runtime（本地模型／运行环境）：让模型在自己的电脑上运行的软件。Runtime 负责运行模型，不等于聊天 App，也不等于 CLI Agent。
• Approval Gate（人工批准关卡）：真正寄信、改文件或执行高影响动作前，先停下来让人确认。

按工作选四扇门

这四扇门不是等级。需要哪一扇才开哪一扇。 多数单次任务只要第一扇；不是工具越多，结果就越好。

入口	五岁也懂的说法	适合什么	动手前先做什么
Chat surface	打开一个对话框，请它先写草稿	写信、解释文章、整理公开信息	移除 Private Data；准备可核对的 Source
App／Connector	帮聊天工具开一扇通往其他服务的门	搜索已授权的邮件、文件或日历	看清读取与写入权限；写入动作保留人工确认

入口	五岁也懂的说法	适合什么	动手前先做什么
CLI Agent	在终端里工作的助手	重复整理文件或执行多步骤任务	限定文件夹，先看 preview／dry-run、command 与 diff，再批准
Local LLM／Runtime	模型在自己的电脑里运行	离线实验，或不想把指定数据交给云端模型	确认选的是 local model；cloud model、web search 或云端功能仍会联网

如果你只想聊天，不需要安装 CLI Agent 或本地 Runtime。

个人 Agent：先说明目标与边界

个人 Agent（Personal Agent） 是能跨工具完成多步骤工作的助手。你先说明目标，它先查资料、写草稿，再拿回来请你确认。这类产品把模型、工具与权限放在一起。产品名称不是底层模型名称，也不是新的升级等级。

这里也纳入消息式个人代理：看它是否保留个人情境、连接日常工具并持续跟进。下表加入初创公司出身的 Instinct、Tab、Tomo 与 Poke。Poke 已加入 Cognition，不再列为独立团队。聊天陪伴、单一提醒工具与企业工作流平台不一定符合这个范围。可用性与隐私细节见下方"账号、数据、权限与费用"。

第一次仍用上面的虚构消息，先不要连接账号。需要跨工具时，再限定它能读取什么、能修改什么，以及何时必须停下来请你批准。发出、发布、删除文件或付款前保留 Approval Gate。"持续工作"不代表可以跳过人工检查。

CLI Agent 的安全起手式：

1. 在测试文件夹放几个可还原的虚构文件。
2. 先要求 read-only plan 或 preview／dry-run。
3. 把可读写范围限制在那个文件夹。
4. 看清 command 与 diff，再批准小步骤。
5. 执行后人工检查；不要一开始就让它发信、删除文件、付款、push 或 deploy。

可以慢慢加入的低风险流程：

• 语言练习：请 AI 扮演对话伙伴；每次只纠正两个错误，最后由你核对教材。
• 周记草稿：只用你愿意放进工具的笔记；先列事实，再写摘要。
• 公开文章摘要：附上原文，要求每个重点指出 Source 段落；自己打开原文检查。
• 虚构文件整理：先在测试文件夹 preview 新文件名，人工批准后才改名。

常见问题：

• 回答猜了不存在的数据：缩短任务，明写"不知道就放进 Needs confirmation"。
• Connector 找不到数据：先检查原服务权限、方案、workspace 管理员与支持的 surface。
• 本地模型很慢：先换较小模型；不要把"跑得动"误当成"回答一定正确"。
• 不知道选哪个入口：先用 Chat surface 完成第一题；真的需要读外部服务、改档或离线时再开其他门。

9.6 要点回顾与复习索引

• 研究人员：claim 要有 citation，citation 要能打开核对；找不到证据就写「未支持」，不要硬补引用。
• 开发者 ：plan → 人工批准 → 小改 → diff → test → review → commit，每一步都要能停下、能回滚。
• 教师：先看校方政策，练习用虚构数据，AI 只做草稿，成绩与纪律决定权在人。
• 知识工作者：三者别混------App/Connector 是桥、MCP Server 是协议端点、Workflow Automation 是流程。
• 日常用户：四扇门按需要开，不需要装 CLI 或本地模型；发出、删除、付款前保留人工确认。
• 共同底线：来源可核对、权限最小、有人负责、能撤销。

角色	最该记住的一句	最容易踩的坑
研究人员	引用不等于支持	把模型推测写成作者 claim
开发者	先读 diff 再合并	测试绿了就放行
教师	AI 草稿、教师定稿	把学生数据贴进工具
知识工作者	每个行动项要有 owner 与 due	AI 编造负责人与截止日
日常用户	先给材料再要结果	把私密数据当上下文发出去

本篇速查卡

复习时只看这张表：看到关键词能接出后半句，说明这一关过了。

关键词	一句话记忆
Eval Case	固定题目 + 成功条件 + 输入，七字段一套
Outcome / Trajectory	结果对不对 / 过程合不合理，两类错误分开抓
Grader	照规则批改，能自动也要能人工抽查
Trace	一次任务的完整时间线，定位「哪一步坏了」
Approval	高风险动作前的人工闸门
Checkpoint / Resume	停下来还能从原地继续
Idempotency	重放不会重复扣款、重复发信
Agent-as-Judge	让另一个 Agent 照规则挑错，但要防同源偏见
Autonomy Gradient	风险越高，自主范围越小
Sandbox	决定出错时能坏到哪里的边界

参考资料：awesome-agentic-ai-zh ------ 一份把 Agent 从「模型基础」一路带到「上线工程」的中文学习地图。