本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想要一个结论：绝大多数人用不好 Agent 工具，不是因为工具不够强，而是因为把"提需求"当成了"下指令"。Agent 的能力上限，取决于你能不能把一件模糊的日常工作，翻译成"目标 + 上下文 + 约束 + 交付物"四件齐全的可执行描述；而稳定性上限，取决于你有没有把跑通过一次的流程，用技能包（Skill）固化下来。这两件事做完，才轮到谈定时触发、浏览器接管、多端协同这些听起来更酷的部分。 本文把这条路径拆成七个环节：先讲清楚 Agent 内部到底怎么干活（感知—规划—行动—反馈的循环、工具调用协议、云端沙箱），再讲任务描述的四件套模板和正反例对照，然后是 SKILL.md 的三层渐进式加载机制和一份可以直接照着改的技能模板，接着是浏览器自动化的定位原理与安全边界、长任务跑偏的四种上下文失败模式及对应解法，最后是把一条手动流程升级成无人值守闭环的四个成熟度阶段。文末附了一份 30 条的避坑自检清单。

想看完整拆解，往下翻。

一、为什么"功能我都懂，就是用不起来"

1.1 一个很割裂的体验

我自己折腾这一类工具已经有一段时间了。市面上叫得出名字的 Agent 产品，从国内的到国外的，装了卸、卸了装，来回好几轮。每次新版本发布，我都会认真看一遍功能说明：会调工具了、能读文件了、支持多智能体协同了、可以接管浏览器了、能跑定时任务了。

看的时候是真觉得厉害。

然后关掉页面，回到自己的电脑前，继续手动整理表格。

这种割裂感我猜很多人都有。功能列表看得懂，演示视频也看得明白，但一到自己身上就卡住了——不知道该把哪件事交给它。不是不想用，是脑子里"我的工作"和"这个工具的能力"这两套东西，压根没接上线。

后来我想明白了一件事：功能是按"能力维度"组织的，工作是按"场景维度"发生的。 产品经理告诉你"我支持文件读取、联网检索、代码执行"，这是三个能力；但你脑子里的问题是"每周五那两个小时抄数据的活儿能不能省掉"，这是一个场景。从三个能力推导到一个场景，中间隔着一层需要你自己完成的翻译工作。

这层翻译，没人替你做。所以真正的门槛不在工具那边，在你这边。

1.2 三个最常见的误区

我踩过的坑，基本可以归成三类，说出来给你避一避。

误区一：把 Agent 当成更好用的搜索框。

刚上手的时候，我最常干的事就是丢一句话进去："帮我分析一下这个行业。"然后等着看它给我什么。给出来的东西通常也不差，条理清楚、结构完整，但拿到手上没法直接用——因为我心里其实有一套隐含的要求（要覆盖哪几个维度、给谁看、多长、什么格式），这些我一个字都没说。

Agent 不是读心术，它只能基于你给的信息做最合理的猜测。你给的信息越少，它猜测的空间越大，跑偏的概率就越高。

误区二：只描述结果，不描述过程。

这是比第一个更隐蔽的坑。有人会说"我说清楚了啊，我要一份 Excel，包含哪几列，按什么排序"。结果确实描述清楚了，但中间怎么走没说。

比如你要它去几个平台统计数据，你没说数据以哪个口径为准、遇到某个平台打不开怎么办、两处数字对不上听谁的。Agent 遇到这些岔路口，会自己做决定。它做的决定不一定错，但很可能不是你想要的那个。等你拿到结果发现口径不对，返工的时间比手动做还长。

误区三：跑通一次就以为稳了。

这个最坑人。第一次运行效果很好，你很兴奋，第二天同样的话再说一遍，出来的东西不太一样；第三天又变了个样。你会怀疑是不是模型抽风了。

其实是因为自由发挥的空间还在。你每次输入的措辞有微小差别，Agent 每次遇到的网页状态有微小差别，这些微小差别累积起来，输出就漂了。解决办法不是把提示词写得更长，而是把流程沉淀成技能包——这一点后面第四节会展开讲。

1.3 什么样的活儿值得交给 Agent

不是所有事情都适合。我自己现在有一套很土但很好用的判断标准，做成表格给你看：

一条经验法则：先挑"高频 + 低判断 + 高容错"的活儿开刀。 这类任务即便 Agent 做得不完美，你的修正成本也很低；而它每周替你省下的时间是实打实的。等这条流程跑顺了，再往判断复杂度更高的地方推。

还有一个反直觉的筛选角度：优先挑你最讨厌的那件事，而不是最耗时的那件事。 最耗时的活儿往往复杂度也高，改造周期长，容易半途放弃；而你最讨厌的那件事，通常是机械、无聊、没有成就感的——这恰恰是 Agent 最擅长的类型。改造完之后的心理收益也更直接，会推着你继续往下做第二条、第三条。

反过来，一上手就挑那种"一年一次、每次都不一样、错了没法补救"的硬骨头，大概率是自己给自己找不痛快。辛梓煜@词元二号站 这边最早就是这么翻过车的，白白浪费了两周。

二、Agent 到底是怎么干活的

要把工作交出去，你得先大致知道对方是怎么干的。这一节我尽量用白话讲清楚原理，不涉及代码也能看懂。

2.1 从"回答问题"到"完成任务"

传统的对话式 AI，本质上是一个函数：你给一段文字，它返回一段文字。中间不碰任何外部世界的东西。

Agent（智能体，可以理解成"能自己动手干活的 AI"）多了两样东西：工具和循环。

工具让它能碰到外部世界——读文件、查网页、运行代码、操作浏览器、写入表格。循环让它能连续做很多步——做一步，看看结果，再决定下一步做什么。

就这两样东西的加入，把"回答问题"变成了"完成任务"。

2.2 一次任务在内部经历了什么

我画一张图，把一次典型的任务执行拆开：

flowchart TD
    A[接收任务描述] --> B[理解目标 + 读取上下文]
    B --> C[拆解成子步骤 / 生成执行计划]
    C --> D{选择工具}
    D --> E[调用工具执行]
    E --> F[把执行结果读回上下文]
    F --> G{目标达成了吗}
    G -- 否 --> H[修正计划]
    H --> D
    G -- 是 --> I[整理交付物]
    I --> J[产出文件 / 报告 / 表格]

这个循环是 Agent 的骨架。每一轮循环里，模型都会重新看一遍"我现在知道什么、我手上有什么工具、我离目标还差多远"，然后决定下一个动作。

关键点在于：这个循环的每一轮，都在往上下文里追加内容。 工具返回的原始数据、中间的思考、失败的重试记录，全都堆进去。堆到一定程度，模型的注意力就开始分散、判断开始漂移。这就是第六节要讲的上下文工程要解决的问题。

2.3 工具调用与 MCP：白话版

Agent 怎么知道自己有哪些工具可用？

最早的做法是把每个工具的说明书（叫什么名字、干什么用、需要哪些参数）写进系统提示里。模型看到说明书，就知道该在什么时候调用什么。

问题是每接一个新工具，就要写一套对接代码。你想让 Agent 读某个代码托管平台的仓库，写一套；想让它更新某个协作文档，再写一套。每套都要处理各自的认证方式、各自的数据格式。集成的工作量是乘法级增长的。

MCP（Model Context Protocol，模型上下文协议）就是来解决这个的。 它被形容为"AI 界的 USB-C 接口"，通过提供一套通用的接口标准，消除了长期困扰开发者的碎片化定制集成问题。

MCP 是 Anthropic 在 2024 年提出、2025 年 12 月捐给 Linux 基金会的开放协议，底层基于 JSON-RPC 2.0——一种使用 JSON 数据格式通信的轻量级远程过程调用协议。协议本身定义了三类核心能力：

到 2026 年，MCP 在整个技术栈中已经接近普及：主流模型厂商都在旗舰模型中集成了原生支持，LangChain、CrewAI、LlamaIndex 这类开发框架也把它从实验性功能变成了工具调用的默认协议。

一个最小化的工具调用请求长这样，你不用会写，看懂结构就行：

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "read_spreadsheet",
    "arguments": {
      "path": "./data/weekly.xlsx",
      "sheet": "汇总"
    }
  }
}

服务端执行完，把结果按同样的格式返回，Agent 读到结果，继续下一轮循环。就这么简单。

这里有一个值得注意的代价：在典型的 MCP 实现中，客户端连接服务器时通常会通过 tools/list 请求获取所有可用工具的完整 JSON Schema，可能立即消耗数万个 token。所以工具不是接得越多越好——接十个用不上的服务，等于每次对话都先烧掉一大截上下文预算。按需连接，用完断开，这是我现在的习惯。

2.4 本地执行 vs 云端执行

现在主流的 Agent 工作台，基本都提供两种执行环境，差别值得说一下。

本地执行：Agent 直接操作你这台电脑上的文件、软件、浏览器。优点是能碰到你的真实工作环境，缺点是电脑得开着，而且一旦出错影响的是你的真实文件。

云端执行：任务丢到一个隔离的远程沙箱里跑。这类 Cloud Agent 能在远程环境中运行任务，避免本地设备性能和环境配置的限制；对于长时间运行的任务，用户无需持续保持电脑在线。更实用的一点是任务并不依赖当前对话窗口持续运行——关闭页面、切换设备甚至手机进入后台，任务依然继续。

我的分配原则很直接：

• 涉及本地文件整理、需要用你已登录的浏览器身份操作的 → 本地
• 纯信息检索、纯内容生成、跑得久又不需要你盯着的 → 云端
• 定时任务 → 尽量云端，不然半夜电脑关了任务就断了

2.5 记忆：让它记住"我们的规矩"

还有一块能力容易被忽略，但用起来非常上瘾——记忆。

Agent 的记忆一般分两层。短期记忆就是当前会话的上下文，关掉窗口就没了。长期记忆是把一些稳定的事实、偏好、约定抽取出来单独存下来，之后的每次对话都能读到。

它的实际价值在于：把那些"每次都要重复交代一遍"的东西一次性说清楚。比如：

- 我的数据统计口径统一按自然周计算，周一为一周的开始
- 输出文件默认存到 ./output/，文件名带日期前缀
- 所有报告都要在开头给三句话结论，我先看结论再看细节
- 涉及数字的地方必须标注来源，不确定就写"待核实"

这几条一旦进了长期记忆，你后面的每一次任务描述都可以少写四行。日积月累，省下来的输入量相当可观。

但有两个坑要提醒：

第一，别把临时的东西写进长期记忆。 "这次先只处理前 10 个文件"这种一次性约束，写进去之后会污染以后所有任务。长期记忆里只放长期成立的规则。

第二，定期清理。 我大概每两个月会翻一遍自己的记忆条目，把过时的删掉。有些规则是三个月前定的，工作方式早就变了，留着只会让 Agent 按老规矩办事，然后你还找不到原因。

记忆、技能包、任务描述这三者的分工，我是这么理解的：记忆管"我是谁、我的习惯是什么"，技能包管"这类事情怎么做"，任务描述管"这一次具体做什么"。 三层各司其职，别混着写。

三、把工作拆成 Agent 能执行的形状

这一节是全文最实用的部分。前面讲原理是为了让你理解为什么要这么写，这一节直接给模板。

3.1 任务描述四件套

我现在写任务描述，固定按四块来：目标、上下文、约束、交付物。缺一块，出错的概率就上一个台阶。

目标：这件事做完之后，世界应该发生什么变化。注意不是"你帮我分析一下"，而是"产出一份能让我在周会上直接过一遍的对比结论"。目标里要包含使用场景和读者对象。

上下文：Agent 不知道但你知道的东西。数据在哪、口径是什么、以前是怎么做的、有哪些行业黑话需要解释。这一块是最容易被漏掉的——因为对你来说太理所当然了，理所当然到你意识不到需要说。

约束：什么不能做、什么必须做。字数范围、格式要求、必须覆盖的维度、不能引用的来源、遇到冲突时的优先级。约束越具体，自由发挥的空间越小，结果越稳。

交付物：最终要什么。文件类型、结构、每一部分放什么、放在哪。

3.2 一份可以直接改的模板

【任务目标】
产出一份 ______，用于 ______ 场景，读者是 ______。
判断这份东西合格的标准是：______。

【背景信息】
- 数据来源：______
- 统计口径：______
- 相关背景：______
- 术语说明：______

【执行要求】
1. 第一步先做 ______，做完把中间结果保留在 ______。
2. 第二步 ______。
3. 遇到 ______ 情况时，按 ______ 处理，不要自行决定。
4. 数据冲突时，以 ______ 为准。
5. 不要 ______。

【交付物】
- 文件类型：______
- 结构：______
- 保存位置：______
- 完成后请自检以下几项：______

看起来啰嗦，但填一次就能反复用。我自己每类任务都存了一份填好的模板，下次直接改几个字。

3.3 反例与正例对照

光讲抽象的没意思，上对照表。我用一个虚构的场景：假设你要整理某类公开信息做成一份汇总。

差别不在文字量，在信息密度。左边那一列，Agent 需要自己猜八九个决策；右边这一列，它只需要执行。

3.4 把验收标准写在前面

这是我后来才养成的习惯，收益特别大：在任务描述里就把验收标准写进去，让 Agent 自己先检查一遍再交付。

【交付前自检清单】
- [ ] 所有条目的字数是否都在限制内？
- [ ] 是否出现了原始资料里没有的信息？
- [ ] 缺失项是否都标注了"未提及"而不是留空？
- [ ] 排序是否正确？
- [ ] 文件是否已保存到指定目录？

这几行加上去，返工率下降非常明显。原因不复杂：你把"检查"这个动作显式地放进了执行循环里，它会真的走一遍，而不是生成完就直接扔给你。

顺带说一个小技巧：自检项要写成能判断真假的句子。 "内容是否详实"没法判断，"每项是否都在 80 字以内"可以判断。凡是自检项里出现了"是否合理""是否充分""是否清晰"这类词，基本等于没写——因为它一定会回答"是"。把这些换成能数、能查、能比对的具体条件，自检才有意义。原理也不难理解——你把"检查"这个动作显式地加进了执行循环里，Agent 会真的走一遍这个循环，而不是生成完就直接交。

这套"角色设定 + 任务边界 + 自检清单"的方法，其实已经是目前公开的 Agent 使用指南里比较主流的思路了，能不能拿到相对完整的交付物，很大程度上取决于任务描述是否足够细致。

四、用 Skill 把流程固化下来

前面讲的是"怎么把一次任务说清楚"。这一节讲的是"怎么让这件事不用每次重说"。

4.1 提示词和技能包的区别

提示词是一次性的。你这次写得很好，下次要么复制粘贴，要么凭记忆重写——重写就会有偏差，偏差就会带来不稳定。

技能包（Skill）是把提示词升级成一个可复用、可版本管理、可分享的文件。本质上相当于给 AI 发放一本专业手册，AI 不会每次都从零学习，而是根据任务自动调用手册里的知识。过去我们用提示词教 AI 做事，现在可以把提示词加资源打包成技能包，更高效也更可靠。

这个升级带来三个直接好处：

1. 不用每次重说，Agent 自己判断该不该用
2. 规则集中管理，改一处全局生效
3. 可以分享，团队里其他人装上就能复现同样的流程

4.2 三层渐进式加载：为什么写了一堆规则却不占上下文

这是 Skill 机制里我觉得设计得最漂亮的一点。

写过 SKILL.md 的人会发现一件反直觉的事：你辛辛苦苦写的那堆东西，99% 的时间根本没被加载进上下文，Agent 只有判断相关时才会读进去。这就是 Progressive Disclosure（渐进式披露）机制。

分三层：

即使装了 50 个技能，初始的上下文消耗也只有约 5000 token。

用一个更直观的比喻：这就像你办公桌上摆着一排文件夹。平时你只看得见文件夹外面贴的标签（第一层），需要哪个才抽出来翻开（第二层），翻开之后发现里面还夹着附件，用到了再拆开看（第三层）。

flowchart LR
    A[会话启动] --> B["扫描全部技能<br/>只读 name + description"]
    B --> C{任务命中<br/>某个技能?}
    C -- 否 --> D[正常回答，不加载]
    C -- 是 --> E[加载 SKILL.md 正文]
    E --> F{需要模板/脚本?}
    F -- 否 --> G[按正文规则执行]
    F -- 是 --> H[按需读取附加文件]
    H --> G

4.3 description 是唯一的命中开关

理解了三层加载，你就明白一件事：description 写得好不好，直接决定了这个技能会不会被触发。

description 是唯一的命中开关——写得含糊，Skill 永远不会被触发。

我总结的写法要点：

• 写触发场景，不写功能名称。"处理表格"不如"当用户上传 xlsx/csv 文件并要求清洗、汇总、透视、生成图表时使用"。
• 把用户可能说的原话塞进去。用户不会说"执行数据清洗流程"，他会说"这表太乱了帮我整整"。描述中的关键词应该与用户的自然表达习惯匹配，以提高触发准确性。
• 同时写清楚什么时候不该用，避免和其他技能抢触发。

对比一下：

# 触发率很低的写法
description: 数据处理技能

# 触发率高的写法
description: >
  用于清洗和汇总杂乱的表格数据。触发条件包括：用户上传 xlsx/csv/tsv 文件
  并说"太乱了""帮我整理""合并一下""做个透视""统计一下各项占比"；
  或者要求把多个表格合并去重、补齐缺失值、生成汇总图表。
  不处理纯文本文档和 PPT，那些交给对应技能。

4.4 写一个自己的 SKILL.md

下面是一份可以直接照着改的骨架。我用一个通用化的虚构场景：把杂乱的周度数据整理成固定格式的汇总表。

---
name: weekly-data-digest
description: >
  把多个来源的周度原始数据整理成统一格式的汇总表。触发条件：
  用户提到"周报数据""这周的数据整理一下""几个表合并成一个"
  "按上周的格式做一份"；或上传多个 csv/xlsx 并要求汇总。
  仅处理结构化表格，不处理文字类周报。
---

# 周度数据汇总技能

## 一、执行前必做
- 列出所有待处理文件，确认数量与用户预期一致，不一致先问。
- 检查每个文件的表头，若表头不统一，按下方映射表对齐。
- 记录每个文件的行数，写入 NOTES.md，供最后核对。

## 二、字段映射表
| 原始表头（可能的多种写法） | 统一后字段 |
| --- | --- |
| 日期 / 时间 / date | 统计日期 |
| 数量 / 总数 / count | 计数 |
| 来源 / 渠道 / channel | 来源渠道 |

## 三、处理规则
- 缺失值统一填 "未提供"，禁止填 0，禁止猜测。
- 重复行按"统计日期 + 来源渠道"去重，保留后出现的一条。
- 日期统一格式化为 YYYY-MM-DD。
- 遇到无法解析的文件：跳过，记录到"异常清单"，不要中断流程。

## 四、交付物
- 输出 summary.xlsx，含两个工作表：
  - Sheet1「汇总」：统一字段的完整数据
  - Sheet2「异常清单」：跳过的文件及原因
- 保存到 ./output/ 目录。

## 五、交付前自检
- [ ] 汇总表行数 = 各文件行数之和 − 去重行数？
- [ ] 是否还有非 YYYY-MM-DD 格式的日期？
- [ ] 异常清单是否完整？
- [ ] 文件是否落到 ./output/ ？

这份东西的价值在于：它把你脑子里那套"我一直是这么做的"的隐性规则，变成了显式的、可执行的、不会因为你今天心情不好而遗漏的文字。

4.5 什么该写成脚本，什么该交给模型

这是写技能包时最容易搞反的一件事。

对于复杂的、需要精确执行的任务，优先使用脚本而不是依赖大模型生成。比如数据导出场景，与其让模型生成 Excel 二进制内容（容易出错），不如写一个专门的脚本处理，SKILL.md 里只需要指导智能体何时调用这个脚本。

我的分界线：

一句话概括：确定性的活儿写成代码，模糊性的活儿交给模型。 把确定性的活儿交给模型，就是在给自己制造随机故障。

五、浏览器接管：让 Agent 在真实网页上替你操作

这一节讲的能力，是"能出报告"和"能替你干活"之间的分水岭。

5.1 网页操作难在哪

生成一段文字很容易，任何模型都会。难的是让 Agent 打开一个真实的网页，找到那个输入框，把内容填进去，再点对按钮。

难点有三层：

第一层，页面结构对机器不友好。 一个现代网页的 HTML 动辄几万字符，里面绝大部分是样式、脚本、埋点，真正的交互元素混在其中。让模型直接读 HTML，等于让人从一整本电话簿里找一个没记全的号码。

第二层，元素定位不稳定。 传统自动化脚本用 CSS 选择器或 XPath 定位元素，页面改版一次，路径就全废了。维护成本高得吓人。

第三层，身份问题。 大部分有价值的操作都在登录之后。Agent 用一个全新的浏览器打开页面，看到的是登录墙。

5.2 无障碍树 + Ref：现在的主流解法

第一层和第二层的问题，现在的通行做法是用**无障碍树（Accessibility Tree）**替代原始 HTML。

无障碍树本来是给屏幕阅读器这类辅助技术用的。浏览器基于 DOM 构建出一棵简化的语义树，只保留对交互有意义的元素——按钮、输入框、链接、标题——并标注每个元素的角色（role）和名称（name）。

这棵树对 AI 简直是量身定做的：体积小了一两个数量级，语义还更清晰。

配合上 Ref 标识机制，定位问题也解决了。所谓 Ref，就是给快照里的每个交互元素分配一个临时编号，模型不需要知道 CSS 路径，只要说"点 e4"就行。因为 Ref 绑定的是元素的语义而不是路径，页面结构调整不影响定位。

一个典型的快照长这样：

{
  "snapshot": "e1:heading '登录', e2:input '账号', e3:input '密码', e4:button '登录'",
  "refs": {
    "e1": { "role": "heading", "name": "登录" },
    "e2": { "role": "textbox", "placeholder": "账号" },
    "e3": { "role": "textbox", "type": "password" },
    "e4": { "role": "button", "name": "登录" }
  }
}

模型看到这个，直接就知道该往 e2 填什么、该点 e4。整个过程不需要任何 CSS 选择器。

操作指令也变得极其简洁：

# 打开页面并取快照（只要交互元素）
agent-browser open https://example.com/login
agent-browser snapshot -i --json

# 按 Ref 操作
agent-browser fill @e2 "账号"
agent-browser click @e4

这套机制的意义在于：它把"操作网页"这件事，从脆弱的脚本工程，变成了模型可以直接推理的语义任务。

5.3 登录态继承：为什么这一步是关键

第三层的身份问题，解法是让 Agent 使用你已经登录的浏览器环境。

打个比方：过去的浏览器自动化像是"实习生第一天上班"——什么权限都没有，你让它查个订单、找个文档，它先是打不开内部系统，然后被各种登录页劝退。而接入了登录态之后，它更像"空降的老员工"：常用网站已经是登录状态，Cookie 和本地存储直接可用，不用重复登录，用的就是你真正在用的那个浏览器环境。

实际操作时，你会在浏览器上方看到一条"正在被自动化工具控制"的提示条。这条提示是功能，不是 bug——它保证了你随时知道现在是谁在操作。看到它出现在你没预期的时候，立刻中断。

会话状态还可以持久化：第一次登录后保存会话，之后的任务直接复用，不用每次重新走一遍登录流程。

5.4 安全边界：这几件事我不交给浏览器 Agent

能力越大，越需要划清边界。我自己划了几条红线，建议你也划：

关于权限，MCP 的设计规范里说得很明白：用户同意与控制是安全性的基石，实施者应提供清晰的界面让用户审查和授权活动；由于工具调用涉及任意代码执行，调用任何工具之前都必须获得用户的明确同意。

这不是官方的客套话。你在把一个能自主决策的程序接到自己的真实账号上，多问一句"它现在能做什么、最坏能造成什么后果"，永远不亏