从会说话，
到会做事。

先有一个，能接着聊下去的模型。

它怎样组织一句回答，又怎样知道现在轮到谁说话？

2022 年 11 月 30 日，OpenAI 公开推出 ChatGPT。许多人开始直观地感受到：对着一个输入框，可以提问、追问、让它改写，也可以让它解释代码。要理解后来能做事的 Agent，我们先回到这个会对话的模型。原始发布 （外链）

职责：帮助用户修改当前项目。
流程：理解目标 到 查阅相关文件 到 修改 到 验证。
工具：读取结果后再行动，检查每次调用是否成功。
边界：只执行授权范围内的操作。
交付：说明修改、证据，以及仍未完成的事项。

能接着聊，就会一直记得吗？

假设你说“把刚才的回答缩短一点”，模型要知道“刚才”是什么，就需要看到相关历史。回到图解 01 的“今天的天气很 到 好”：多轮对话也是同一件事，只是已有上下文换成了按角色拼起来的整段历史。

所以对话不只是这次输入的一句话；应用要为它组织上下文，缓存只是让重复的部分便宜一些。接下来，新的问题出现了：历史越积越多，总不能永远塞下去。

压缩是用更精简的状态继续任务。让模型总结旧对话是常见做法，也可以删去过期的工具输出、把资料移到外部文件。压缩腾出的是空间，窗口本身没有变大。

问题也出在这里：摘要会丢细节。比如第 2 轮你说过“酒店每晚 500 元以内”，压缩后可能只剩“预算有限”；到第 9 轮要订酒店时，窗口里已经找不到这个数字。所以只靠压缩不够，重要的内容还要另存一份，需要时再取回来，这就是记忆。按内容还在不在窗口里，可以分成两类。

换个角度看，一段内容能不能算长期记忆，要看它能不能被找回来。凡是能从外部找到、再放进对话的内容，都可以当作长期记忆：另存的聊天记录、整理好的用户偏好、项目里的文档和代码、知识库，甚至一次搜索或数据库查询的结果。习惯上，关于用户和这次任务的内容叫记忆，公共资料叫知识库；但对模型来说，它们都是被取回、放进窗口的文字。反过来，存了却找不回来，或者找回来没放进窗口，模型这一轮就用不上。长期记忆存在哪里、怎样取回，下面用工作台和档案柜来看。

能不能别只告诉我，替我做一下？

一个直观的尝试：让模型输出动作，让程序真正动手。

会对话以后，人们自然会想：它既然能理解要求，能不能替我操作软件？在原生工具接口普及之前，一种常见办法是先在提示词里约定格式，再由程序解析输出、调用函数。模型不用直接控制鼠标，只需要表达“下一步应该点哪里”。

目标：打开浏览器，搜索“Agent 入门”，再向下浏览结果。
每轮看当前截图，只输出一个动作，不加解释：
tap(x, y)                         点击指定位置
input(text)                       向已聚焦的输入框输入文本
scroll(fromx, tox, fromy, toy)     从 (fromx, fromy) 滑动到 (tox, toy)
参数格式：坐标用整数，文本用 JSON 双引号字符串。
成功后输出 done；无法判断时输出 ask("需要确认的问题")。

可用工具：tap，作用是点击画面位置。
需要调用时，只返回 JSON，不要附带说明：
{"tool":"tap","arguments":{"x":整数,"y":整数}}

{"tool":"tap",
 "arguments":{"x":92,"y":116}}

{ "name": "tap", "arguments": { "x": 92, "y": 116 } }

把同一思路搬到代码里

点击、输入和滚动是工具，读取文件、编辑代码、执行测试也是工具。后文会用“修好登录测试”继续说明：模型提出请求，程序执行并回传结果。

MCP，把模型接到真实环境里。

把外部能力做成能发现、能理解、能调用、能返回结果的接口。

{
  "jsonrpc": "2.0",
  "id": "rpc-1",
  "method": "tools/list"
}

{
  "jsonrpc": "2.0",
  "id": "rpc-1",
  "result": {
    "tools": [{
      "name": "tap",
      "description": "在 800×450 的桌面画面上点击指定位置。",
      "inputSchema": {
        "type": "object",
        "properties": {
          "x": { "type": "integer", "minimum": 0, "maximum": 799 },
          "y": { "type": "integer", "minimum": 0, "maximum": 449 }
        },
        "required": ["x", "y"],
        "additionalProperties": false
      }
    }]
  }
}

{
  "messages": [
    {
      "role": "system",
      "content": "根据最新截图选择动作；不确定时询问用户。"
    },
    { "role": "user", "content": "打开浏览器。" }
  ],
  "tools": [{
    "type": "function",
    "function": {
      "name": "desktop_tap",
      "description": "在 800×450 的桌面画面上点击指定位置。",
      "parameters": {
        "type": "object",
        "properties": {
          "x": { "type": "integer", "minimum": 0, "maximum": 799 },
          "y": { "type": "integer", "minimum": 0, "maximum": 449 }
        },
        "required": ["x", "y"],
        "additionalProperties": false
      }
    }
  }]
}

{
  "role": "assistant",
  "content": null,
  "tool_calls": [{
    "id": "call_7",
    "type": "function",
    "function": {
      "name": "desktop_tap",
      "arguments": "{\"x\":92,\"y\":116}"
    }
  }]
}

{
  "jsonrpc": "2.0",
  "id": "rpc-2",
  "method": "tools/call",
  "params": {
    "name": "tap",
    "arguments": { "x": 92, "y": 116 }
  }
}

{
  "jsonrpc": "2.0",
  "id": "rpc-2",
  "result": {
    "content": [{
      "type": "text",
      "text": "已执行点击 (92, 116)。"
    }],
    "isError": false
  }
}

{
  "role": "tool",
  "tool_call_id": "call_7",
  "content": "{\"content\":[{\"type\":\"text\",\"text\":\"已执行点击 (92, 116)。\"}],\"isError\":false}"
}

点了一下以后，谁来决定下一步？

把前面的截图例子展开，就能看见 Agent 的执行循环。

浏览器可能没打开，输入框可能没聚焦，搜索也可能失败。只调用一次工具，事情不一定完成。系统需要把结果重新交给模型，让它判断接下来该做什么。你刚才看到的“看截图、选动作、执行、再看截图”，就是第二章核心机制卡片里第 2 到第 5 步的重复；第 1 步是用户提出的需求，它决定什么时候算完成。

本文讨论的 LLM Agent，是围绕目标、根据环境反馈持续决定下一步行动的系统。模型承担理解和决策工作，外围程序提供执行环境。一次工具调用结束后，系统还要判断：结果是否有用？需要继续尝试吗？什么时候可以交付？

history = [规则, 用户目标]
for step in range(MAX_STEPS):              # 步数上限，防止无限循环
    reply = model(history, tools)          # 一次 LLM 请求
    history.append(reply)
    if reply.tool_calls:                   # 模型请求使用工具
        for call in reply.tool_calls:
            if needs_approval(call):       # 发消息、删数据等先问人
                return WAITING(call)       # 保存状态，等人回复
            result = run_tool(call)        # 程序真正执行
            history.append(tool_result(call.id, result))
        continue                           # 带着结果再问一次模型
    if passes_acceptance(reply, history):  # 用证据核对验收条件
        return COMPLETED(reply)
    history.append("还没满足验收条件：…")  # 说明缺什么，继续
return STOPPED("达到步数上限，任务未完成")

循环能自己跑了，但有些决定必须交回人

再往前走一步：假如下一步要把调研结果发给客户，发送与否应该由用户确认，模型觉得写好了也一样；如果两条需求冲突，继续试错也解决不了。于是，我们在循环里设置检查点，保存状态、暂停相关动作，等人给出明确反馈后再决定如何继续。这就是 Human in the Loop 的一种典型用法。

人的作用也不只是点击“批准”：可以纠正目标、补充资料、选定方案或评价结果。系统因此要把“等待人回复”和“任务已完成”区分开；等待时保留可恢复的状态，避免恢复后丢掉原先的约束或重复执行动作。

会用工具了，为什么每次还要重新教？

Skill 把说明、流程和可执行资源放在一起，让经验能够复用。

假设 Agent 已经能读取文件、运行 Python，也能通过 MCP 查数据。你每周让它统计一份订单表，却发现：这次算了取消订单，下次漏掉退款，报告格式也不一样。工具都在，缺的是“这类任务应该按什么规则、什么步骤来做”。

你可以每次粘贴一长段要求，但规则很难维护，任务不相关时还会占用上下文。把这套方法整理成可复用的 Skill，便能让 Agent 在处理这类任务时找到并采用它。2025 年 10 月 16 日，Anthropic 推出 Agent Skills；同年 12 月 18 日 将其发布为开放标准。这里说的是这一具体能力包格式，复用提示词和操作方法的实践早已存在。原始发布 （外链）

一份说明书，解决三个反复出现的问题

Skill 通常以 SKILL.md 为入口，记录名称、用途和处理方法，并可附带脚本、参考资料与素材。它可以很简单，只有一份说明；也可以是包含多个资源的目录。Skill 不是给模型重新训练权重，而是在需要时提供做事方法。[S1]

weekly-orders/
分支-- SKILL.md                  适用场景与流程
分支-- references/
|   底部-- metric-rules.md       统计口径
分支-- scripts/
|   底部-- summarize_orders.py  校验与计算
底部-- assets/
    底部-- report-template.md   输出模板

“固化流程”，哪些交给说明，哪些交给程序？

说明书约定“先检查、再统计、最后解释”，模型根据任务选择与理解；脚本负责不该每次自由发挥的规则，比如金额字段是否合法、订单能否计入、如何精确求和。提示词提高一致性，脚本与校验才把明确的处理规则落到执行逻辑里。若必须严格保证步骤顺序，还应由宿主或工作流控制。

python scripts/summarize_orders.py --input orders.csv

说明越来越多，又会把上下文塞满，怎么办？

如果有几十个 Skill，一开始就把全部正文、脚本和参考资料放进去，会挤占当前任务的上下文。渐进式披露把加载分层：先知道“有哪些说明书”，匹配任务后再读正文，需要细节时才取具体资源。[S1]

脚本可以直接由执行工具运行，只把必要输出送回模型；不必每次把整份源码都读进上下文。需要审查或排错时再读取代码。具体发现、加载和执行方式由支持 Skill 的宿主实现，单独放一个目录并不会自动让任意模型获得该能力。

“查找 Skill”和“加载 Skill”，到底是谁在做？

先把 Skill 理解成一个带说明书的文件夹：入口是 SKILL.md，旁边可以放参考文件、脚本和模板。文件可以保存在本地，也可以由远程服务提供。所谓“加载”，就是宿主读取选中的说明，把内容加入模型接下来能看到的上下文；文件放在磁盘上，并不代表模型已经读过它。[S3]

接回前面的 MCP：查找和读取 Skill，也可以封装成 MCP 工具。例如我们设计一个服务，提供 search_skills 和 read_skill。宿主通过 tools/list 获得这两个工具的定义，模型再用它们找说明书、读正文。注意，tools/list 列出的是工具；有哪些 Skill，要看搜索工具的返回结果。下面的名称与返回值均为教学设计，并非 MCP 规定的标准工具。

什么时候调用 search_skills、拿什么当关键词，由模型决定。宿主只负责把这个工具放进工具列表，工具描述写着“按关键词查找可用的 Skill”。模型读到用户的话后，自己判断要不要查、查什么。比如用户说“用 weekly-orders skill 帮我生成本周订单报告”，模型就会拿 weekly-orders 当关键词，调用 search_skills({"query":"weekly-orders"})。用户没有点名时，模型从任务里提炼关键词，下面例子里的“订单周报”就是这样来的。查不到时，模型可以换个关键词再查，或者问用户。在这个设计里，宿主不会在每句话之后替模型搜一遍。也有宿主把 Skill 的名称和描述直接放进上下文，或者让用户用命令直接指定 Skill，这时就不需要先搜索。

用户：按团队口径生成本周订单报告。
助手调用：search_skills({"query":"订单周报"})
工具返回：id=weekly-orders；用途=校验订单并生成周报
助手调用：read_skill({"id":"weekly-orders"})
工具返回：SKILL.md 正文、资源位置与读取方式
下一次模型请求：原任务 + 调用记录 + 返回的说明
助手继续：按说明读取口径、执行统计、核对报告

如果这份说明还要求“查询团队的退款政策”，资料从哪里来？可以连接后文的知识库：Skill 组织做法，知识库提供做事时需要查阅的事实。

谁把这一切组织起来？

Harness 负责运行，人参与关键判断。

Agent Harness 可以理解为模型外围的运行框架：组织上下文、驱动循环、执行工具、管理状态，并根据需要提供权限控制、超时、重试和任务交接。模型能力很重要，系统如何组织和验证这些能力同样重要。

现在把前面的部件放到同一次任务里：用户给出目标，记忆与 Skill 提供必要信息，模型提出下一步，工具和人返回反馈。Harness 要负责维持这个过程，还要在上下文过长时压缩、在任务真的完成时退出。

Finish，不是“模型不再调用工具”

模型输出最终答复，只是一个结束候选。应用要按任务定义判断它是否足够：桌面例子要确认浏览器打开、搜索完成且页面已滚动；修复代码则要有对应的验收证据。部分任务可以程序化验证，另一些需要人的检查。Todo 被勾选、最后一次调用成功，都不能单独证明整个目标完成。

还需要防止无效循环：限制尝试次数或运行预算，监测是否反复得到同一错误，必要时请求帮助。停止条件与成功条件分开设计，才能避免“把资源耗尽了”也被当成任务完成。

Human in the Loop 指人在合适的检查点参与。比如 Agent 自动读代码、定位问题、运行测试；遇到两种互相冲突的业务解释时，请人明确预期，再继续执行。人的参与不要求每一步都确认，而应与任务风险和判断需求相匹配。

不同的 Agent，不同的能力组合。

用三个例子，把抽象概念放回真实产品里。

Hermes Agent：能不能把刚才的对话变成 Skill？

前面的 Skill 是人提前写好的说明书。Hermes Agent 还展示了另一条路：任务完成后，让 Agent 回看这次对话、操作过程和参考资料，提炼出以后还能复用的做法。它提供 /learn 这样的入口，既可以指定一份资料，也可以描述“把我们刚才走过的流程整理成 Skill”。[H1]

如果经验在上一次会话里，先要找回相关记录：Hermes 提供 session_search 检索历史对话。把取回的目标、尝试、工具反馈和用户修正作为材料，再请求提炼方法。检索只取回相关的几段记录；提炼出的内容要经过审查和后续任务验证，才算一份合格的 Skill。[H2]

用户：把我们刚才生成周报的流程提炼成一个 Skill。
助手：回看本轮对话，区分临时决定和可复用规则。
助手：整理触发条件、步骤、数据口径、异常处理和验收方式。
助手：写入一个 Skill，供后续任务按需加载。
下次任务：匹配到该 Skill 到 读取说明 到 使用工具执行 到 核对结果

把“手脚”展开看，就知道它们能做什么

先区分名字：Claude 是模型家族，也用于聊天产品的名称；这里比较的是开发工具 Claude Code。下列是各产品官方文档中的基础工具示例，实际可用集合取决于版本、平台、配置和授权，不能因为知道工具名字，就认为当前会话一定能调用。

OpenClaw 的 Gateway，值得单独看一眼

工具解决“能做什么”，但日常助手还会遇到另一组问题：消息从哪里进来？交给哪个 Agent？接上哪段会话？结果发回哪里？OpenClaw 把这些连接与运行协调集中在一个长期运行的 Gateway（网关） 周围，让消息渠道、客户端、Agent 与设备能力可以围绕同一个入口协作。

例如，你从一个聊天渠道发来“帮我查这件事”，Gateway 接收消息并按配置路由到对应 Agent 和会话；Agent 调用工具，结果再交付回相应渠道。它的价值在于把“能运行的 Agent”组织成“能长期接入日常沟通的系统”。跨渠道是否共用同一段上下文，需要明确配置，不能自动视为全部共享。

OpenClaw 官方 Gateway 架构 （外链） · Gateway 是基础设施层，不等同于某个模型或某一次工具调用。Hermes 也提供消息网关；这里突出 OpenClaw 的架构特点，不将网关能力描述为独有。

这里用于比较组织方式，不是产品排名。能力与支持范围会随版本变化，请以官方文档为准。

数字员工：把 Agent 放进云端，接入日常工作。

有工作环境、有岗位规则、有资料可查，也有同事能够找到它的入口。

前面的 Agent 能在你的电脑里完成任务。再往前走一步：同事在 IM 中发一句“生成本周订单报告”，即使你的电脑关机，系统也能接单、查询资料、运行程序，并把结果送回原会话。这一章把这种部署在云端、面向特定岗位工作的 Agent 服务称为“数字员工”，用云端沙盒承载执行过程。它是一种产品组织方式，不是新的模型类别。

把前面的组件装在一起就能理解它：岗位提示词定义职责，Harness 组织循环，沙盒提供工作空间，知识库提供在线检索，MCP 连接业务系统，Skill 提供做法，接口负责接单和交付。以下是一套教学架构；实际部署也可以把 Harness 放在沙盒外，只将命令执行交给沙盒。

先给它一台“工作电脑”：沙盒有哪些形态？

这里的沙盒是为任务划出的执行环境，可以提供文件系统、语言运行时、命令执行和可选浏览器。可视化桌面是可选项。下面按层次列出常见实现思路和产品例子，区分底层隔离技术和已经封装好的沙盒服务，排列顺序与性能无关。

例如周报任务只需要 Python、订单文件和报告模板；浏览器操作任务则还需要浏览器环境。部署时按实际需要准备环境。沙盒可以按任务创建，也可以恢复已有环境；是否保留文件和进程由生命周期配置决定。[D4][D5]

有了环境，怎样让它成为“周报专员”？

先用固定提示词描述岗位，再把真实能力接上。提示词影响模型如何判断，不会自动实现 Harness Loop，也不会凭空生成接口权限。循环、任务调度和权限校验需要运行程序实现。

职责：按团队当前口径生成订单周报。
开始前：明确项目、统计周期和币种，缺失时询问。
资料：从知识库查询生效口径，记录来源与版本。
做法：加载订单周报 Skill，使用已有工具获取和处理数据。
权限：仅在当前任务授权范围内查询数据、生成报告。
完成：统计核对通过，报告附来源，交付到指定会话。
异常：数据缺失、政策冲突或校验失败时说明原因并等待处理。

同事在 IM 里找它，接口怎样配合？

以一个订单周报机器人为例，我们可以设计下面的链路。IM 平台的事件格式和回复接口各不相同；例如 Slack Events API 有事件确认与重试机制，所以入口应及时确认接收，把耗时工作交给后台任务，并避免重复事件触发两次执行。[D6]

1. 接单：同事发送“生成 A 项目本周订单周报”。机器人接收事件，绑定用户、项目与原会话；信息不足时先澄清。
2. 入队：服务校验身份和事件，创建任务标识，返回“已接收”。任务提交、状态查询和确认／取消各有入口，机器人只是这些接口的一种客户端。
3. 执行：Worker 创建或恢复沙盒，Harness 读取岗位规则与 Skill，查询知识库，通过 MCP 获取授权数据，再运行统计脚本。
4. 等待与恢复：若查到两份冲突口径，保存进度并回到原会话提问。收到匹配该任务的确认后继续；未回复保持等待，取消则停止。
5. 交付：核对总额与统计范围，把报告和出处保存到持久存储，再通过 IM 回复接口返回结果；若发送失败，记录交付状态并重试交付，不重复执行整份统计。

让 Agent 更可靠，靠的是证据。

把“听起来完成了”，变成“有依据地完成了”。

渐进式披露解决的是信息组织问题，不是事实真实性的保证。减少无依据结论，需要把信息来源、工具反馈和实际验证放进执行过程。下面七条，可以作为设计或使用 Agent 时的检查清单。

用好 Agent 的实用经验

前面讲机制，这一章讲用法：文档怎么写，能力怎么封装，常见的错误怎样避开，知识库怎样维护，以及大家还在尝试的新做法。

项目文档，也按“先目录、再细节”来写

第五章的渐进式披露不只适用于 Skill，给 Agent 看的项目文档也一样。入口文件每次都会读进上下文，所以要短，只放常用命令、硬性约定和一份文档索引。具体的设计、接口和流程放在单独的文件里，Agent 做到相关任务时再用文件工具打开。Anthropic 把这叫作“及时”检索：上下文里只留文件路径、查询语句这类轻量的标识，需要时再用工具加载内容。[T1]

写入口文件时可以问自己：这句话是不是每个任务都用得上？用不上的就移到具体文档里，在索引里留一行说明。入口越长，留给当前任务的窗口越少，真正重要的约定也越容易被淹没。

新能力做成 Skill 加脚本还是 MCP，先看凭证放在哪里

两种方式都能连接内部系统。Skill 配套的 Python 脚本可以直接调用内部接口，脚本由 Agent 已有的命令工具执行，不需要另起服务。所以区别不在“能不能连”，而在三件事：凭证放在哪里，谁来限制 Agent 能做哪些操作，有几个宿主要用同一套能力。

Anthropic 在讲怎样给 Agent 写工具的文章里提醒，工具不是越多越好。把现有 API 一个接口包成一个工具是常见错误；工具太多或功能重叠，会分散模型的注意力。文章建议只为少数影响大的工作流做几个考虑周到的工具，比如用一个 search_contacts 代替 list_contacts，免得模型自己逐条翻找。[T3] 这篇文章面向的是通用 Agent：每多一个工具，每次请求都要多带一份定义。它讨论的是工具怎样设计，对 MCP 工具和宿主自带的工具都适用，并没有比较 Skill 和 MCP。

上下文开销是克制的直接原因。多数 MCP 客户端一开始就把全部工具定义放进上下文，Anthropic 为此提出另一种用法：把 MCP 服务器呈现成代码接口，Agent 按需读取定义、写代码调用，中间数据留在执行环境里，不经过模型。文中的例子把 token 用量从约 15 万降到约 2000，并提到把写好的函数配上 SKILL.md 就成了一个 Skill。[T4] Flask 作者 Armin Ronacher 也写过，他已经把自己用的 MCP 都改成了 Skill，理由是 Skill 平时只占一段描述，不会把工具定义放进上下文。[T5]

Skill 加脚本连接内部系统，要满足两个前提。第一，运行环境能联网：Claude Code 里的 Skill 和本机其他程序一样能访问网络，而在 Claude API 上运行的 Skill 不能调用外部接口。[T6] 第二，接受凭证放在 Agent 的环境里：脚本通常从环境变量或配置文件读令牌，Agent 能跑的任何命令都能读到同一份令牌，令牌能做的事 Agent 都能做。自己用、只读查询、令牌本身权限很小时，这通常可以接受。

MCP 的优势主要在远程服务。规范要求基于 HTTP 的 MCP 服务器按 OAuth 2.1 授权：每个用户用自己的身份登录，令牌按 scope 限定范围，服务端也不能把客户端的令牌原样转给下游接口。[T7] 这样凭证留在服务端，Agent 只能调用开放出来的几个操作，宿主还能在每次调用前请人确认。本地用 stdio 启动的 MCP 服务器，规范让它从环境读凭证，这一点和脚本读环境变量差别不大。多个宿主共用时 MCP 也更省事；Skill 文件可以复制，但自定义 Skill 不会在 Anthropic 的各个产品之间自动同步。[T6] 代价是工具定义占上下文，工具之间不能像命令那样用管道组合，服务端一改接口，所有宿主都跟着变。

两者经常一起用：MCP 负责把工单系统接进来，Skill 写明“处理退款工单时先查政策、再核对金额、超过限额请人确认”。判断时可以想象把这项能力交给一位新同事：只需要给他一份操作手册，或者一个权限本来就很小的令牌，就写成 Skill 加脚本；如果要给他开一个只能做几件事、离职时能收回的系统账号，就按第三章的方式做成远程 MCP 服务。

减少幻觉：允许说不知道，结论要有出处

幻觉指模型说出看起来合理、实际上不对的内容。2025 年 9 月 OpenAI 的研究者在论文里给出一个解释：常见的训练和评测只按答对多少计分，回答“不知道”得零分，猜一个答案反而可能得分，所以模型被训练成了“会考试的学生”，不确定时也倾向于猜。[T8] 在 Agent 里，猜测会变成后续动作的依据，代价更高。能做的事情主要有四类：

需求说不清时，先让 Agent 来问你

Agent 看不到你心里的预期。它通常按保守的理解去做，交出一个满足字面要求的最小版本；遇到没说清的地方，就自己补一个假设，做完才发现方向不对。Claude Code 的官方建议是：还没想清楚时，不必先把需求写完整，可以让 Agent 先采访你，一直问到能写出规格为止，把结果写进 SPEC.md，再开一个新会话照着它实现。[T9] 这份文件也就是验收标准，第四章说的交付条件有了文字依据。

自己交代需求时，说清三件事：要做成什么样，包括没有数据、出错时怎么办；哪些不用做；怎样才算做好。想要的规模也要说出来。你希望“把边界情况都处理好”，就直接写上，模型猜不出你期望做多大。

长任务会遗忘，关键约束要写进文件

第一章讲过，窗口快满时要压缩，压缩会丢细节。会话一长，开头交代的约束还会被后面大量的工具结果淹没。常见的表现是做到一半又用回了你否定过的方案，或者忘了“不要改公共接口”。

办法是把必须一直遵守的内容放到窗口之外、随时能重新读到的地方。长期有效的约定写进 CLAUDE.md 或 AGENTS.md；本次任务的目标、已经做出的决定和待办，写进一个笔记文件，让 Agent 边做边更新，压缩之后重新读一遍。Anthropic 把这叫作结构化笔记，是长任务保持连贯的常用做法。[T1] 换到不相关的新任务时开一个新会话，免得上一件事的历史一直占着窗口。[T9]

还有几个常见的坑

写代码离不开团队自己的知识

模型从公开代码里学到了通用写法，但它没见过你们团队的东西：内部接口怎么调用，哪个模块不能直接改，为什么当初选了这个方案，测试要怎么跑才算数。这些信息缺了，模型只能按“大多数项目的做法”去猜，写出来的代码看着合理，却和项目对不上。代码本身只记录了“现在是什么样”，很少记录“为什么这样”和“哪些不能做”。

所以要把这类知识写下来，放在 Agent 找得到的地方。量少、稳定的写进仓库文档，按本章开头的方式分层组织；量大或经常变化的，放进可检索的知识库。写的时候优先记录这几类内容：构建和测试命令、目录和模块的职责、接口约定和错误码、做过的重要决定及原因、已知的坑。知识库也需要维护，代码改了文档没改，Agent 会照着过时的说明做事。

两篇文档说法冲突，比缺一篇更麻烦

知识库越大，越容易出现两篇文档说法不一样：旧文档写“退款超过 500 元要审批”，新文档写的是 1000 元；一份接口说明还是 v1 的参数，另一份已经换成 v2。检索时两篇都可能被取回，模型只能挑一个，或者把两种说法揉在一起，答案看起来有依据，其实是错的。研究者把这类情况归为“上下文之间的知识冲突”，是检索增强里常见的问题。[T10] 缺一篇文档，Agent 至少有机会停下来问；两篇冲突时，它往往不知道自己错了。

所以知识库的维护和内容本身一样重要。每个主题只保留一份权威文档，其他地方链接过去；文档写明适用版本、更新日期和负责人；新规定取代旧规定时，删掉旧文档，或者在开头明确标注已经废弃。固定指令里也可以写一句：发现资料互相矛盾时指出来并问人，不要自己挑。扩展 A 的知识库一节讲了检索时怎样核对版本和出处。

让 Agent 顺手维护知识库，改动交给人审

维护文档很费人力，而最清楚刚刚发生了什么的，往往就是 Agent：它刚改完代码，知道哪个命令变了、哪个坑踩过。可以在固定指令或 Skill 里要求它在交付前检查一遍：改过的代码对应的文档有没有同步，这次被纠正过的事值不值得写下来。Claude Code 还提供检查指令文件的命令，标出为旧模型写的规则、指向已不存在文件的条目，以及相互矛盾的条目。[T9] 第七章 Hermes 的 /learn 把对话提炼成 Skill，也是同一个方向。

Agent 写进知识库的内容会影响以后所有任务，一次误判可能被反复照做。所以写入要走和代码一样的流程：以改动差异的形式提交，注明依据，由人审过再合并。让它发现冲突、提出修改是省力的；直接替人决定哪条规定作数，就越过了边界。

Agent 各个部件上的新尝试

前面讲的模型、工具、记忆、Skill 和运行框架，每一块都还有人在试新做法。下面挑几个例子，它们都很新，介绍以项目官网或论文的自述为准，效果还需要更多独立验证。

操作界面：一步一个动作，或一步一段程序

第二章用 tap、input、scroll 演示了最朴素的做法：看截图，做一个动作，再看截图。每一步都要请求一次模型，又慢又贵，坐标也容易点偏。现在有两条改进的路线，Google 的 Artemis 和 2026 年 10 月发表的 OpenGCUA 是两个代表。

自己做选择时，可以先问：这件事有没有程序接口？有就优先用接口，像第三章那样做成工具，界面操作留给没有接口的场景。必须点界面时，按界面结构定位比按坐标稳定；高影响的动作，比如付款、删除、发送，仍然要在执行前请人确认。

操作系统也在为 Agent 改造：Omarchy

Omarchy 是 Ruby on Rails 作者 DHH（David Heinemeier Hansson）发起的 Linux 发行版，基于 Arch Linux 和 Hyprland 窗口管理器，以键盘操作为主，官网称它是“智能体原生”的 Linux。据官网介绍，首次启动时可以选一个默认 Agent，例如 Claude、Codex、OpenClaw、Hermes 或 OpenCode；应用崩溃时，点一下通知就能派 Agent 去读崩溃转储、诊断问题并写错误报告；系统还自带一组 Skill，帮 Agent 制作应用、插件和主题。[T13]

这和前面几章的思路一致：系统配置都是文本文件，命令行工具齐全，Agent 用已有的文件和命令工具就能读、改和验证，用不着截图点界面。和 Artemis、OpenGCUA 从 Agent 这一侧适应界面不同，Omarchy 是从系统这一侧让自己更容易被 Agent 理解和修改。具体功能随版本变化，以官网为准。

运行框架也能插拔，还能在对话里给自己加功能：DeepSeek Harness

DeepSeek 在 2026 年 8 月开源了自己的运行框架 DeepSeek Harness，命令名是 dsh，MIT 协议，目前是预览版。它建立在 Cordis 插件框架上，官网的说法是“一切皆插件”：模型、工具、Skill、会话、沙盒、存储、循环、调度和界面都由插件提供，开发者在配置里选择、替换或扩展，不用改框架源码。[T14] 第六章讲的运行框架各个部件，在这里都成了可以单独换掉的插件，Agent 循环本身也是其中之一。

更特别的是，它可以在对话中扩展自己。在“创造模式”里，用户让 Agent 写一个插件，Agent 可以先查看当前运行时，在内存里试验插件，再安装进去。[T14] 文档里的例子是 Agent 写一份配置组合包，把一个 MCP 服务接进来，再交给插件管理器安装；开启热重载时，新工具直接出现在同一个正在运行的会话里。插件配置保存在当前 profile，重启后仍然有效。[T15] 热重载的做法是先卸载旧插件、撤销它产生的所有副作用，再加载新代码。[T16]

这相当于 Agent 能改自己的工具箱。它和 Hermes 用 /learn 写 Skill 方向相同，只是改动落在框架的代码和配置上，并且会一直留到以后的会话。文档建议修改前先读一遍组合包的改动，装完同时确认插件管理器报告已生效、工具确实调得通，不需要时通过插件管理器停用或移除。[T15] 插件是会执行的代码，别人写的插件要像安装软件一样先审查；项目还在预览阶段，接口会有不兼容的变化。

其他部件上的尝试，本页前面已经讲过一些：Hermes Agent 用 /learn 把对话提炼成 Skill；Mem0、M-flow 等项目把记忆做成可检索的服务；Codex 用子 Agent 拆分任务；E2B、Daytona 提供按需启停的云端沙盒。这些做法变化很快，适合定期回看官方文档。

人们正在努力建造一个新的世界，哪怕这个世界有一天不再需要他们亲手去做那些事。

工具接过去的是做法；留给人的，是想清楚要什么，以及什么才算做好。