Agent 与提效本质之思考

关于 Agent

我们先来回顾一下什么是 Agent。

Agent 通常可被视为能够自主完成任务的智能体：它可以根据环境变化做出决策，并在一定范围内学习和适应新情况。

Agent 由 LLM 驱动，而后者通过深度学习算法与自然语言处理技术，利用目前人类生成的“符号”，如文字/图像等，进行训练，然后通过推理来生成所需的文本。这意味着，Agent 自带的能力很大程度上是由 LLM 的能力决定的，而 LLM 的能力又可以看作是“对人类现有知识（的一部分）的拟合”。因此，Agent 其实具有一定程度的“智力”（注意，与“意识”相区分），这种智力实质上可以极大解放人类的认知负担和注意力资源，而善于利用 Agent 的人，则可能可以把这些宝贵的注意资源放在那些更加宝贵的任务上面去。

提效的核心思路

基于前面的关于 Agent 概念的回顾，我们围绕“注意力解放”的思路来分析一下，当我们在使用 Agent 进行提效时，其核心思路有哪些？下面我总结了一些自己的思考，供读者参考：

1️⃣ 将交流中反复出现的表达需求进行标准化

记得之前在网上看到某位大佬的一句话，大致意思是说：

如果有一件事，提示词让你需要复用三次以上，那么就把它封装成一个 command。

当我们和 Agent 进行交流的过程中，经常会发现有一些需求会反复出现的。例如，在 Coding Agent 里面有一个经常需要做的工作就是 compact，即压缩上下文对话。这个过程虽然在即将超过上下文上限的时候，会自动发生，但在实际的使用过程中，也会有手动压缩上下文的需求。这个时候，Coding Agent 如 Claude Code、OpenCode 等，将这个需求进行了标准化，通过简单的代称 /compact 这个 slash command，实际上大大减少我们在每次需要进行 compact 这个任务时所需要的认知负担和操作步骤。

设想一下，如果每次有这个需求，都要打一堆字和 Agent 交流，那么不仅麻烦，还会增加我们的注意力负担。

那你可能会说，我用打两个字压缩上下文，不是也能达到类似的效果吗？其实人与 Agent 进行交互的时候，二者经常存在一些认知上的不对齐。你的具体需求，未必能让 Agent 通过简简单单几个字就领悟得很清楚，这其实是提供的需求细节与执行效果直接的权衡问题。

而我们通过标准化的方式，实际上是把这个权衡做了一个优化，让我们在表达需求的时候，通过把场景需求标准化的方式，用短的命令引用大段的提示词描述。既能让 Agent 很清楚地理解我们的需求，又能让我们自己在表达的时候，减少不必要的认知负担和操作步骤。这种方式是比较理想的，也是最容易实现的。

2️⃣ 构建自主规划-执行-反馈的闭环

Agent 和纯对话进行交互的 LLM 相比，很大一个区别就是它可以依据给定的目标，自主利用提供的工具，与环境进行交互，并且可以根据工具执行的反馈，自主决策后续的行为，从而实现自主规划-执行-反馈的闭环（关于 agent 与 workflow 的区分，可参考 Anthropic: Building effective agents）。

举一个例子，约在 2023 年前后、以我个人使用体验来看，会有这样的场景：需要写一个脚本，我在网页版对话中向 LLM 说明需求，它帮我写了脚本。我将脚本复制粘贴到 VS Code 中运行，发现报错后又把报错反馈给网页版的 LLM，它给出可能的解决方案。我根据方案手动修改或直接复制完整代码重新尝试，如此重复直到脚本跑通并符合预期为止。

回顾上面的例子，我们可以看到，在这个过程中，人类的注意力资源分配到了哪些环节？

1. 告诉 LLM 我的需求
2. 等待 LLM 生成脚本
3. 把脚本复制粘贴到 VS Code 中
4. 点击运行
5. 等待运行结果，判断是否符合报错/是否符合要求
6. 如果不符合要求，反馈给 LLM。回到第 2 步。
7. 结束

而现在我们使用 coding Agent 的时候，人的注意力资源被分配到了哪些环节？

1. 告诉 Agent 我的需求
   1. Agent 生成脚本
   2. 自主测试，排查是否有报错
   3. 并尝试简单运行，初步判断是否符合需求
2. 等待 Agent 完成上述流程。如果 Agent 还没完成，继续观察等待
3. 判断 Agent 的执行结果是否符合预期。如果不符合预期，反馈给 Agent，回到第 1 步。

可以看到，在这个过程中，Agent 的自主规划-执行-反馈的闭环系统，极大地减少了人类在中间环节的注意力资源占用，让人类能够把更多的注意力资源放在核心的需求表达和功能验收上面去，而不是被那些机械重复的操作步骤和等待时间占用掉。这些看起来是非常简单的任务，但是其实也需要占用一定的注意力资源。如果人的注意力资源都分配到这种繁杂的工作上，那么很快一天能用的注意力资源就会大大缩水。

我们现在使用 Coding Agent 时，实质上相比 LLM 增加了执行以及反馈的能力。传统的复制粘贴方法，只使用了 LLM 的规划能力和编写代码，而实际代码执行和反馈部分都由我们进行，链路中执行、反馈两个并没有打通，无法形成闭环。

而最近一年，Agent 生态开始慢慢变得成熟如开发过程体验已经做得比较好了。有很多原来的环节已经形成了闭环，在效率上实现了质的提升。但在其他一些领域，甚至 Coding 领域本身，还有很多一些环节做得不够好，我们可以和 Agent 一起打通整个规划-执行-反馈的闭环，让这个过程更加自动化，节省我们宝贵的注意力资源。

举个例子，现在在写作的时候，其实是有一些重复性的需求可以做的。一篇比较正式的文章的产出，可能会经历下面几个阶段：

1. 选题确定
2. 大纲构思
3. 文章撰写
4. 文章润色（格式优化、错别字语病纠正）
5. 文章配图
6. 文章发布
7. 文章数据监测

上面只是一个简单的设想，每个人会有不同的流程。但不管怎么样，我们在这个过程中，可能会发现有一些环节是比较机械重复的，例如文章润色、文章配图、文章发布、文章数据监测等，这些环节其实是非常适合 Agent 来做的。我们可以通过一些工具的打通，让 Agent 来帮我们完成这些环节的工作，从而让我们把注意力资源更多地放在选题确定、大纲构思、文章撰写这些更需要创造力和思考的环节上面去。

我最近正在研究的一件事情是，利用 Coding Agent 来帮我搭建一个专门用于文章撰写的仓库，把重复动作尽量沉淀成”可复用命令 + 可复用脚本”。换句话说，我的目标不是让 Agent 帮我”写观点”，而是让它帮我稳定处理那些可流程化的环节。

我最初使用的是 OpenCode，后来迁移到了 Claude Code。选择 Claude Code 的原因主要是：它自带的权限检查和更改预览机制比较适合这种需要自己 review 的场景；与 VS Code 的集成也很好，可以直接在编辑器里选中文章段落让 Claude Code 修改，实现 90% 不离开 VS Code 就能完成操作。

不过，选用什么 Coding Agent 并不重要，重要的是这套处理日常工作流的思路。这种思路可以拓展到写作以外的任何领域：对于那些需要长期重复完成的智力型任务，如果能用 Agent 将其自动化，那么用得越多，节省下的注意力资源就越多，复利效应会越来越明显。

这里给一个我目前正在探索的写作提效流程，下面有请 OpenCode 进行介绍：

在进入具体步骤前，先把这条 OpenCode 流水线的“入口和边界”说清楚：

1. 入口分成两段：先用 /polish @doc/article/xxx.md 跑完“格式化 → 事实核查 → Markdown 增强 →（按需）配图”，再用 /publish @doc/article/xxx.md 生成发布版并把本地图片替换为可发布的 CDN 链接。
2. 细粒度能力由原子 skill 负责：format 只做中英数间距，fact-check 负责抽取可核查陈述并给来源与改写建议，markdown-enhance 做轻量标注增强，illustrate 负责生成配图资产。
3. 脚本与 Agent 有明确分工：tools/ 里的 Python 脚本负责稳定执行（格式化、渲染、上传等），不做语义判断；语义决策与取舍仍由 Agent + 人类验收共同完成。
4. 流程执行上优先“并行化非阻塞检查”：像格式检查、链接核验、素材准备这类不阻塞主线的任务，尽量后台并行，最后统一汇总，避免主线程被低价值等待占满。

下面这三张截图，分别对应这条流程里“编排入口、事实核查改写建议、工作区差异验收”三个关键触点：

1 先做格式一致性处理（降噪）

• 用 python tools/quick_format.py <draft.md> 对草稿做中英数间距标准化。
• 如果我只想先看差异，不直接覆盖，就跑 python tools/quick_format_check.py <draft.md> 生成预览稿。
• 这一步的价值很直接：先把低价值但高频的排版动作清掉，避免我在后续修订时被格式噪音打断。

2 再做内容层修订（事实、论据、表达）

• 事实核查用 /fact-check，重点盯时间、数据和来源链路。
• 论据补强用 /strengthen，让 Agent 补证据、补反例或补边界。
• 综合修订用 /revise，统一语气、读者对象和篇幅约束。
• 这一步本质是把“我反复口头说明的修订要求”标准化成 slash command，减少沟通磨损。

3 做一次轻量标注增强（不改原意）

• 用 markdown-enhance 审阅文章，对技术词、命令、路径等补充反引号。
• 对关键判断句做适度加粗；若确有必要，再补 1-3 个外部参考链接。
• 原则是宁缺勿滥：非必要不改句式，不改观点，不改结论。

4 最后做配图与发布前资产准备

• 配图链路使用 skill("illustrate") 和 tools/illustrate.py，密钥统一从 .env 读取。
• 如果文章里有流程图，再走 tools/mermaid_render.py 输出高清图，避免手工截图导致分辨率不稳定。
• 到这一步，基本可以把注意力收回到“信息是否准确、观点是否成立、结构是否清晰”这三个核心问题上。

这里要强调一个边界：tools/ 里的脚本只负责格式化和资产处理，不做内容判断；内容判断仍然交给 Agent 的检索与推理链路。也就是说，脚本负责稳定执行，Agent 负责语义决策，人类负责最终验收。

因此，这套做法真正解决的不是“省几分钟操作”，而是把注意力从机械步骤中抽离出来，持续投入到选题、论证和表达这些高价值环节。只要这个闭环跑顺了，写作提效才是可持续的。

当然，这个流程只是我目前的一个初步探索，未来还会不断迭代优化，例如添加各个平台的自动发布（个人博客、各论坛、Telegram 群组、小红书、x 等）。

在其他不同领域，也会存在类似的问题，我们按照打通上述三个规划-执行-反馈流程闭环的思路思考和分析这些工作，并进行交互与迭代，相信会节省很多宝贵的注意力资源。

3️⃣ 使用推送模式而不是轮询方式

在日常生活中，我自己会有一些所谓的“信息焦虑”的情况。对于那些我感兴趣的信息，我会不断刷新查看，总想着最早得到最新的信息。为此我之前还专门写了一个工具（练手软件，不推荐使用，且后文有更好解决方案），方便统一查看各个平台分散的信息。但是后来我发现，很多时候，当信息产生变化时，有一个 hook 能够以合理的方式通知我，就没必要花这么多注意力资源去不断查看了。

例如聊天软件就是这样的特征，当别人给你发消息时，手机会监听到消息并通过声音或震动告知你，你再进行查看即可。我们把这两种现象进行抽象，结合从之前开发过程中了解到的 Telegram 机器人的两种工作模式，即 polling 与 webhook 得到的灵感，可以将这两种模式简单归纳为轮询和推送（可参考 Telegram 官方 Bot API 文档）。

我们的目的是尽可能用“推送”的方式，把那些值得我们关注的信息，在真正发生变化的时候通知我们，而不是靠我们不断“轮询”来查看是否变化。

比如以我当前使用配置中的 OpenClaw 为例（具体能力以版本与文档为准），我让它做了很多定时任务：每天帮我收集关注的 RSS 信息源、软件更新版本、市场价格变动等一系列我感兴趣的消息，时间间隔可设为每天、每半天或其他任意时长，然后总结推送给我。这样我就不用每天打开电脑或手机就想着去查看它们的数据及最新变化，而可以把宝贵的注意力资源放在更值得做的事情上。

从技术上来讲，OpenClaw 也是使用定时轮询的方式来做的。但是这就是 Agent 这个代理帮我们解放注意力资源所在。我们只需要和它进行交互即可，它帮我们轮询去查找信息，我们在值得被通知的时候被推送消息就行了。换句话说，把“轮询动作”交给 Agent，本质上是在回收人类注意力。

结语

在这个节奏越来越快，信息越来越碎片化的时代，Agent 的出现为我们提供了一个非常有价值的工具，可以帮助我们解放注意力资源，让我们把更多的注意力放在那些真正重要和有价值的事情上面去。一个人的注意力资源是每个人最为宝贵的资源之一，善于利用 Agent 的人，才能够在这个时代更好地生存和发展。

本文使用我的doc agent辅助创作，Powered by OpenCode。部分图片使用 AI 生成。