从网站、周报、汇报材料、知识库到学习体系，我对 Agent 工作边界的一些理解

---

最近我把这段时间用 AI Agent 干过的活翻了一遍。

一开始我以为会整理出一份“工具清单”：用了哪些模型、插件、自动化能力和 prompt。真写起来才发现，最值得复盘的不是工具，而是一个变化：

我怎么一点点把 Agent 从“帮我生成内容”，用到了“帮我跑一段流程”。

生成内容，是让它帮你写一段话、做一页材料、整理一个表格。跑流程，是让它理解目标、读取材料、操作工具、处理中间结果，最后交付一个可以检查的产物。

前者解决一次问题。后者开始接近一种新的工作方式。

这段时间我做的事情看起来很杂：网站页面、周报自动化、Excel 分类、汇报材料、知识库分析、学习计划、客户事件报告……但背后有一条线：

不是问 AI 能不能做，而是不断拿真实工作去试：哪些环节能交给 Agent，哪些判断必须留在人手里。

先说一下我这段时间主要用过的几类 Agent 工具。

Codex 桌面版 / CLI：更适合代码、文件、文档、表格、网页素材这类“在本地工作区里持续改”的任务。桌面版适合多线程、长任务和结果 review；CLI 更适合直接在命令行里快速处理项目。Claude Code：更像一个工程协作型 coding agent，适合在代码库里读文件、改文件、跑命令、沉淀 skill。我在浏览器自动化、Excel 处理、流程复盘这类任务里用得比较多。OpenClaw：更偏“个人桌面 Agent / 自动化工作台”的方向，适合探索本地化、长期运行、连接不同工具和渠道的场景。但这类工具早期也更容易遇到部署、版本和稳定性问题，适合拿来探索边界。

简单说，Codex 更像工作区里的执行伙伴，Claude Code 更像工程任务里的协作者，OpenClaw 更像桌面自动化和个人 Agent 的试验场。它们不是互相替代的关系，更像不同工作形态下的几种入口。

01 从想法到一个能打开的网站

搭建一个轻量网站页面，是我最早感受到 Agent 价值的场景之一。

这类工作以前会被拆成很多块：页面结构、视觉风格、文案表达、代码、部署、后续修改。Agent 介入以后，它可以先帮你拆页面结构，再把结构变成页面，最后陪你反复调文案、调层级、调风格。

但我真正需要盯住的，不是每个技术细节（技术细节AI搞定），而是：

这个页面要给谁看？看完希望对方记住什么？哪些表达可以明确写，哪些要保守写？哪些信息涉及合规和授权，不能随便放？

这件事给我的启发是：

Agent 能把一个“我想要个东西”的模糊想法，推进到“这里有个链接，你可以打开看看”。

很多工作卡住，不是因为我们完全不会，而是从想法到成品之间有太多小台阶。Agent 的价值，就是把这些小台阶铺起来。

02 不只是做 PPT，而是重新理解“汇报材料”

过去我们默认：一说到汇报，就是 PPT；一说到宣传，就是长图；一说到分析，就是 Word 或 Excel。用 Agent 多了以后，我发现交付形态其实可以更灵活。

比如用 HTML 做可打开、可滚动的分析报告；用 reveal.js 做可翻页、有进度的网页 PPT；用 HTML/CSS 做手机端长图海报；用 Markdown 先组织结构，再让 Agent 转成不同展示形态。

重点不在某个工具。工具只是载体。真正重要的是，Agent 更擅长根据结构生成材料：

WHY背景：客户当前遇到什么问题？HOW挑战：为什么现有方式不够？WHAT方案：我们如何解决？PROVE价值：客户最终得到什么？

只要结构说清楚，它就能把内容变成可阅读、可演示、可复用的材料。后续修改也可以从“调版式”变成“调表达”：

把第二部分改得更像客户汇报，少讲技术实现，多讲业务影响。

很多材料不一定非得从 Office 软件开始。只要目标是表达，HTML、Markdown、网页报告都可以成为交付形态。

手机海报也是类似逻辑。真正的问题不是“好不好看”，而是可读性、适配性、滚动体验和信息层级。把这些坑沉淀成规范，下次就不是重新做一张图。

03 那些很碎的周报工作，最适合被 Agent 接住

另一类典型场景，是内部系统里的重复操作。

有一项周报相关工作，过去每周都要从系统里筛选新记录，再逐条打开详情，把客户、产品、销售、测试场景、开通时间等字段整理进 Excel。

这类工作有个特点：

每一步都不难，但每一步都要人盯着。

登录系统、选时间、筛条件、翻页、点详情、复制字段、粘贴到表格、检查格式、避免重复录入。说它复杂吧，也没有多复杂；说它简单吧，每周都做一次，确实烦。

后来我让 Agent 接管后半段流程。人的部分只保留必须人工完成的动作，比如登录确认。后面的筛选、翻页、识别记录、打开详情、提取字段、写入 Excel，则交给 Agent 配合自动化工具完成。

更关键的是，做完一次以后，我让它反过来总结流程，沉淀成一个 skill。下一次只要告诉它日期范围，它就知道要跑哪套流程。

最值得自动化的，不一定是最难的工作，而是最稳定、最高频、最消耗注意力的工作。

04 混乱材料，不要急着写，先让它长出结构

还有一类工作，是处理客户材料。

比如有一次要整理一份技术规范修订建议表，里面有几十条内容，涉及功能、性能、合规、服务、商务、边界确认等多个方向。

如果直接逐条看，很容易陷入一种状态：每条都重要，但不知道从哪里开始说。

我让 Agent 先做的不是“写一份总结”，而是先分类：

请不要先给结论。先逐条阅读原始内容，按以下维度判断：1. 这是功能能力问题，还是服务/商务/合规问题？2. 是明确不支持，还是需要进一步澄清？3. 哪些条目适合放到客户会议上重点沟通？4. 哪些只是措辞修订，不应升级为方案风险？

这个提示词里有一个关键点：先判断，再写作。

最后产出的不是一份普通表格，而是一份可以拿去开会的沟通材料：重点关注、分类汇总、明确不支持、重点沟通、待澄清项，都被拆开了。

类似的还有对接公司 Wiki 做文档分析。接入知识库之后，Agent 可以围绕已有文档做检索、归纳、对比，甚至把整理后的内容写回指定位置。客户侧发生安全事件时，也可以让 Agent 按时间线和攻击者路径整理 HTML 报告，比单纯写“事件经过”更清楚。

业务材料的难点，往往不是写得不够漂亮，而是结构还没有浮出来。

Agent 很适合做第一轮结构化。但结构出来以后，哪些结论能讲、哪些边界要收、哪些措辞要谨慎，还是要人来判断。

05 AI 帮我学习，不是替我学习

我还用 Agent 做了一件很有价值的事：帮我固定学习过程。

这里不只是“用 AI 学 AI”。AI 可以帮我学 AI 网关、MaaS、RAG、模型路由，也可以帮我学一个新产品、一套开源项目、一类客户场景。

以前我也会收藏资料、看文章、问概念。但看完不代表会用，收藏不代表理解。

后来我开始用类似 spec 的方式组织学习：

每个主题写成一个 spec：学习目标、核心概念、示例、常见误区、验收问题。

比如学习 Tokenizer，不是停留在“它负责把文本切成 token”，而是要能回答：为什么 token 会影响成本？为什么上下文窗口不是“字数窗口”？客户问费用估算时，这个概念怎么解释？

AI 最有价值的地方之一，不是替你学会，而是帮你把“我到底算不算学会了”这件事说清楚。

学完以后，不看材料能回答验收问题，才算完成。

06 提示词不是模板，而是工作意图

用多了以后，我越来越觉得，提示词不是玄学，但也不是“背几个万能模板”。

第一，做研究时，不要把结论塞进问题里。

不要问：

为什么 A 方案比 B 方案更适合客户？

更好的问法是：

请比较 A、B、C 三种方案：1. 各自适合什么场景？2. 主要风险是什么？3. 在什么条件下 A 不一定更优？

研究类任务要尽量开放，让 AI 帮你找可能性，而不是证明预设立场。

第二，要建议时，先说目标，不要只说动作。

不要只说“帮我优化这个 Excel”。可以改成：

我要拿这份 Excel 和客户开会。目标是快速识别争议点、明确哪些能满足、哪些需要澄清、哪些可能影响商务边界。请先设计分类方式，再输出适合会议沟通的版本。

第三，复杂任务先让 Agent 反问。

在开始写之前，请先问我 3 个会影响输出质量的问题。

很多时候，不是 Agent 写得差，而是我一开始没交代受众、场景、边界和最终用途。

第四，做完以后追问一句：能不能复用？

请把这次过程总结成一个可复用流程：适用场景、输入材料、执行步骤、检查项、下次可复用的 prompt 或 skill。

这一步经常比当次输出更值钱。

07 一些坑和新的困惑

现在很多 Agent 工作，某种程度上是在做“马绳”：给 AI 套上工具、流程、约束、上下文、检查点，让它能稳定往前跑。英文里有人把这类工作叫 Harness Engineering。

这件事现在很重要。因为模型虽然强，但还不是每次都稳定。我们需要 spec、workflow、skill、检查清单，让它少跑偏。

但这些“马绳”会不会只是阶段性经验？

比如我之前用过一些开源 Agent 工具，早期部署麻烦，使用中也有 bug。后来版本迭代以后，部署变简单了，bug 也修复了，很多原来靠经验绕开的坑直接消失了。

今天很重要的经验，可能明天会被产品化；今天必须手工搭的马绳，可能以后会被模型能力或 Agent 框架直接吸收。

所以现在学 AI，有点矛盾：不亲手试场景，就不知道边界在哪里；但很多细碎技巧的生命周期可能很短。

但这不代表不用学。只是要分清楚：哪些是短期工具经验，哪些是长期能力。

短期经验包括某个工具怎么装、某个参数怎么配、某个 bug 怎么绕。长期能力则是：如何定义问题，如何拆流程，如何给上下文，如何设计验收，如何判断结果是否可用。

还有一个更重要的坑：

AI 的能力和结果，不等于你的能力和结果。

Agent 输出了一份很漂亮的材料，不代表我很强；它跑通了一段流程，也不代表我已经掌握了这套能力。

如果我不知道它为什么这样写，不知道结果有什么风险，也不能在客户追问时解释清楚，那这个结果并没有真正变成我的能力。

AI 时代，人更要想清楚自己的价值在哪里。不是和 AI 比谁写得快、谁总结得多，而是判断方向、设定标准、识别风险、理解现场、做最终取舍。

结尾：探索得足够多，才知道边界在哪里

回头看，我最大的收获不是“我用 AI 做了很多事”，而是对边界更敏感了。

一个任务适不适合交给 Agent，我现在会先看几个条件：

规则是否稳定？输入材料是否足够？步骤能不能描述清楚？结果有没有办法验收？中间是否涉及必须由人判断的业务、合规、承诺边界？

如果这些条件比较清楚，Agent 往往能接得住。如果目标含糊、材料不足、验收标准也没有，那它就容易变成一个“看起来很努力，但结果不稳定”的助手。

所以我现在不太问“AI Agent 能不能替代谁”。这个问题太大，也太容易空转。

我更关心的是：

我手里哪些工作已经足够流程化，可以让 Agent 接一段？哪些判断仍然必须由我来做？

人不是从流程里消失了，而是位置变了。

人负责方向、边界和取舍。Agent 负责把大量中间过程跑起来。

它不是一个神奇按钮，更像一个可以被训练进你工作流里的执行伙伴。

你给它越多真实材料，它越懂你的现场；你沉淀越多流程，它越能复用上次的经验；你越清楚目标和边界，它越不容易乱跑。

最后真正变强的，可能不只是 Agent。

而是你开始重新审视自己的工作：哪些是判断，哪些是执行；哪些是经验，哪些可以变成流程；哪些事情每次都重新做，其实早就该沉淀下来。

这才是我这段时间用 AI Agent 干活，最有价值的一点。

---

最后补几个这段时间反复用到的技术名词，方便有兴趣的人继续查：

playwright-cli：让 Agent 操作浏览器，适合处理需要登录、点击、筛选、翻页的网页流程。CDP：Chrome DevTools Protocol，用来连接已经打开的 Chrome，适合保留人工扫码登录这类动作。openpyxl / Excel COM：读写 Excel，处理格式、公式、样式和兼容性问题。MCP：让 Agent 接入外部系统或知识库，不只是靠复制粘贴材料。reveal.js：用网页方式做可翻页、有进度的演示材料。spec / plan / skill：把目标、步骤、验收和复用流程固定下来，减少每次从头解释。Codex / Claude Code / OpenClaw：我这段时间主要使用的几类 Agent 工具，分别更偏本地工作区、工程协作和桌面自动化探索。