# 小龙虾（OpenClaw）观察日记（更新中……）
**URL:** https://meta.appinn.net/t/topic/81432
**Category:** 稻米鼠的频道
**Created:** [2026 年2 月 8 日 13:53 UTC](https://meta.appinn.net/t/topic/81432 "2026-02-08T13:53:24Z")
**Posts on this page:** 11
**Page:** 1
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 8 日 13:53 UTC](https://meta.appinn.net/t/topic/81432/1 "2026-02-08T13:53:24Z")
> [!important] 为我家的小龙虾求点口粮
> :lobster:
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
最近大概一周左右的时间，在疯狂地使用小龙虾（OpenClaw），就这么称呼吧，在语音输入法下英文不太方便。
- 它是很好用的
- 他是很烧 token 的
- 它也是不完善的
- 它的发展是非常快的
在使用中确实存在一些技巧，或者只是经验，再或者 只是因为它尚不完善，所以存在一些需要人工补足的细节。
前一篇中我已经说过： **如果你购买了一个机器人，你要做的就是打开开关，然后问它应该如何使用** 。理论上，小龙虾确实认真地向这个方向努力了。但在实际情况中，受到种种因素的影响，效果并没有想象中那么好。
## 安装篇
其实它的安装非常简单，NPM 一键安装，只不过一条指令的事情。之后，之后就是有引导的配置过程。
但这里并不是安装教程，我自己也不知道如何配置。不过有一个非常小白友好的消息，Cherry Studio 里面自带了小龙虾的一键安装。我测试下来非常的简单，可以说是真正意义上的一键安装。
找到位置以后，点击安装，你需要的就是等待，这个过程中可能会有一个 node.js 需要联网的提示，点击允许就行了。安装好以后就可以直接运行了，如果遇到状况可以尝试重启 Cherry Studio。如果界面白屏，可以刷新一下。
他直接跳过了安装引导。当然，你会问模型怎么设置？在启动前，你可以选择 Cherry Studio 中你已经设置好的模型，只需要选择一下，就会自动设置好。
然后就可以直接使用 WebUI 进行聊天了。不过我觉得这个界面有蛮多 bug 的，真的不怎么好用。但起码，他先打通了你与 AI 之间的交流途径。剩下的可以问 AI 进行操作。
## 交流渠道
并不想讲那些大家都会讲的。其实我在 AI 的辅导下也配置不明白。
说一个坑：它的网页界面只支持本机打开，所以如果跨设备，可能需要做一下反代。如果直接使用 IP 打开，可能导致其中的一些文件锁住，当然，也不算太大问题就是了。
但是，其实它是支持 API 调用的，只是不知道为什么，几乎没有人讲起这件事情。所以理论上用一个 AI 聊天的客户端就可以接入它进行聊天了，当然这个默认是没有开启的。我今天测试了一下，可能需要自定义一下请求的 Headers，但这样的自定义，我不知道哪个客户端能够完美支持。反正今天使用 AI 给出的 curl 命令确实成功跑通了，但是还没有找到能够配置成功的客户端。
## 初始化
一个非常容易被忽略的点。第一次和他交流，他会让你做一些设定，但是基本上都是非常简单的几个问题。在对他完全没有了解的时候，如果问题多了，确实体验会不太好。但只是这样极其简单的设定其实留下了大片的空白，对日后的使用影响还是非常大的。
所以最好在你准备好之后，让他带着你再对这些初始设定进行一下补全。或者你也可以手动翻阅它 workspace 下的文件名大写的几个文件。
这件事情非常重要。
## 关于记忆
官方的默认记忆方案其实挺简陋的，只是靠规则去进行规划和规范。而且官方的方案也属于逐步完善的，所以如果安装得比较早，到后期可能还需要自己在这方面对 AI 进行一下补全。
首先，最好自己理解官方的分层记忆方案。如果不理解，就让 AI 给你讲解一下。以下我直接说一些要点。
- 如果想让他记住某件事情，要强调记一下，记住它。这样的关键词应该能够触发他将这些信息写入日记。而日记是他以后会进行检索，查找记忆的位置。
- 如果一个设定你希望它长期保持，应该写入长期记忆。但他 workspace 下那几个文件名大写的文件，其实都属于长期记忆。毕竟设定文件也属于长期影响它的。所以不同信息类型，最好让它自己决定存入哪个文件。
- 在一定情况下，它会触发自动的压缩上下文，但这个操作就可能导致信息的丢失。所以应该在上下文长度达到一定值的时候，也就是距离被压缩比较近的情况下。让它先将当前上下文中的重点信息进行保存。
可以安装一下官方的记忆技能，差不多就能做到上面这些了。
## 工作手册
理论上它是内置文档的，而且自带文档查询工具。但有时候也会觉得他工作得怪怪的。所以可以参照如下方案：
- 让他克隆官方仓库，但只要 docs 文件夹；
- 让他克隆官方的 skills 仓库，但只要其中所有的 md 文件。
- 让他自己书写一个日后更新这两个仓库的脚本。
这样你就可以让他在本地文档里检索最新的文档和技能了。如果性能许可，最好安装一下 QMD 之类的工具来提升检索速度和效果。如果不安装，它也可以自己使用 grep
命令进行检索。
## 稳定性
我觉得在使用中首先需要的是模型对指令的遵循能力。然后，如果模型在计算机和编程方面的能力足够强的话，那它能实现的效果还是相当令人惊叹的。
你可以要求他，对于任何事情的回答，要有结论，有证据链。对于任何文件都要先读取再使用，避免在使用前被其他程序或者你自己修改而导致与他记忆中的内容不符（说直白点，就是避免他的幻觉）。
然后一些常用操作尽量让它写成脚本，这样在它运行脚本的时候，就不太容易出现与预期不一致的状况。
## 定时器
其实就是定时自动向大模型发送一个预定的指令。这非常的提示词工程，提示词书写的好坏直接影响它的执行效果。因为你希望它自动运行，所以在运行过程中是没有人类监督的。所以要线性地讲清楚每一个步骤，并且在最后让他进行检验，来确保效果。最好这个执行是可以生成日志的，或者让它自行记录日志。这样方便你回查具体的状况。
如果真的出现问题，也可以让他进行自查，多数时候他是能够给出可以接受的解释的。
然后定时器最好自己检查一下。稍微复杂一些的状况，让他自己去设定，最终的结果常常不如人意。如果再反复修改，就会越来越乱。
你需要检查它设置的时间间隔。以及发送的提示词。
## 避免卡住
因为它的主智能体是单线程的。如果你连续向他发送消息，会有一个消息队列，它逐个进行处理。在这个过程中，如果再有定时器激活，状况就会有些热闹。更可怕的是，如果它正在运行某个命令，可能就需要一直等待命令的结果。而命令如果再卡住……事情就变得更加有意思了。
所以这时候要实行 MCSW 策略。即 Main chat，sub work。要求它主线程只用来聊天，任何复杂的、需要等待的、可能造成卡顿的工作，全部都交给子线程去完成。这个优化策略是应该官方去做的，然而似乎没有做。总之，你最好认真地去要求他实行这个策略。（写入某个设定文件中。）
## 子线程
第一个非常重要的问题：子线程是不带上下文的，全靠主线程向他交代任务。所以主线程交代任务的能力是非常重要的。如果主线程交代任务不清楚，子线程必然是无法准确完成的。所以尽可能使用好的模型，能极大地提升使用体验。
然后子线程可以设置的参数其实非常多，这不需要你手动设置，但如果有需求，一定要和 AI 交代清楚。
调用子线程可以指定模型，也可以指定模型是否开启思考。这样就可以让擅长这件事情的模型去做了。
然后对于像定时触发这种和重复执行的情况，如果涉及子线程，最好让 AI 把交给子线程的提示词先写好，写在文档内，在执行的时候直接复制过去。避免每次重新生成提示词导致的效果不一致。而且你也可以预先检查提示词，杜绝某些歧义。尽可能向子线程交代清楚具体的操作方法，并给出各种示例。
## 遇到问题
让他自己修，或者让他指导着你修。（ **非常重要的前提：要用足够强的模型，否则就是以其昏昏，使人昭昭** ）。而对于所有操作，都要求他查证文档，给出相应的证据链。这样多数时候是能够解决问题的。
如果修改配置，请一定要让它先备份再修改。这样，如果因为修改配置导致它无法启动，你只需要将备份恢复过去就可以了。也就是你并不需要明白什么道理，就可以方便地把它解救回来。
## 持续性
不要相信那些他自己逛论坛玩之类的事情。它没有我们想象的那么灵活。多数时候还是我们说一件事情，都做一件事情。只是它可以持续地完成一个稍微复杂一些的工作流。但并不太能持续不断无休止地工作。
所以长期的自动工作还是要依靠定时器去不断触发。或者一些其他方法去不断触发它。
虽然想象起来很美好，但实际……真的很吃 token。开不起呀。
## 关于上下文
现在模型可以接受的上下文长度算是非常长了。然后和小龙虾很多时候我们并不会去新开一个对话，既然能够一直聊天，谁还会去考虑其他事情呢？这很合理，但这也导致，几乎每一次请求，他都带了巨大的负荷。虽然聊得很爽，但是 token 的消耗量也确实很大。目前感觉正常的一天聊下来。不是持续的，就是时不时聊两句，大概相当于让他陪着你工作的状态。一天两三千万 token 的消耗差不多。如果聊得频繁，应该可以轻松上亿。
所以，如果你聊完某个话题以后，打算转换话题，其实可以让他先压缩一下上下文的。这样也避免前面的内容占比比较大，引发他产生幻觉。
* * *
今天先到这里吧，其他的问题想起来再说。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 9 日 00:39 UTC](https://meta.appinn.net/t/topic/81432/2 "2026-02-09T00:39:49Z")
## 两个工具链
### 搜索
默认自带的是 Brave Api，需要自己去注册，注册需要绑定银行卡，这非常麻烦。而且免费额度是每月 1000 次，感觉每天问他几个问题很可能就能消耗光。
可以在技能里搜索 DDG，其实就是 duckduckgo，这个是免费的而且不需要 key 的，一般用用也是能够满足的。
Tavily 也是一个非常常用的搜索服务，注册和获取key都很简单，免费也是每月1000次搜索，但是不需要绑定银行卡。
Jina 这是一个网页读取服务，它也有搜索功能，而且他家有专门给 AI 看的文档，把文档丢给自己的小龙虾让他学习就好（记得让它固化成技能，否则下一次用可能会忘掉）
然后上述工具可以做一个优先级排序，让他根据需求依次调用尝试。当然多次尝试其实就是多次请求，所以 token 的消耗量是会增加的。
### 网页读取
自带的 web fetch，功能过于基础，很多网页是读不了的。
让他操作浏览器或者使用无头浏览器能够解决大部分，情况但是速度相对慢一些，另外就是性能消耗比较高。
Jina 的网页读取服务确实非常好用，免费赠送 1,000 万词元，我用到的并不多但是不知道这东西能够让我免费用多久。可能用完了就再注册一个免费账户吧。
Readwise 好像是这么拼写，好像是稍后阅读服务，用亚马逊账号就可以登录，获得免费 Api，可以将网址存入，可以读取存入的内容，可以删除存入的条目……这样就可以变相透过它去读取网页内容，当然速度可能稍微慢一点。不过看起来限制最宽松，好像只有一个每分钟请求次数的限制，个人使用基本是不会超出去的。
* * *
这些东西选择以后或者安装技能，或者让 AI 学习以后固化成技能，并且对于工具调用策略需要在他工作空间的 TOOLS.md 中进行一些规定。主要是为了避免每次都重新教他。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 9 日 00:54 UTC](https://meta.appinn.net/t/topic/81432/3 "2026-02-09T00:54:02Z")
## 关于记忆
这必然是一个很麻烦的事情。最简单的办法是使用上下文足够长的模型。但依然会带来各式各样不可预知的问题。所以进行适当的手动管理还是必要的。
理论上你可以和他说记下来，记住这件事情。强调以后，他应该将这件事情写入他的日记。后面你问起的时候，他应该可以自己去搜索日记。 **当然这些都是理论，具体效果和实际使用的模型有关** 。
### 长期记忆
你可以认为这是你对模型的设定，在任何对话中他都应该记住的部分，写在 MEMORY.md，工作空间下的一些其他文件也有类似的作用，有时候我分不清楚会让他自己选择应该写入的文件。
### 他的日记
理论很好，现实可能经常跑偏。可以安装一下官方的技能进行加强。但更多的是你自己记得提醒他一下，这样可能比较稳。
然后上下文占用比较大的时候应该有自动保存的机制，就是检测到上下文的占用达到某个数值它就会优先将现在上下文中的信息进行整理写入日记，这样一旦遭遇上下文压缩能够快速的恢复重要记忆。
但是有一些模型在你提醒他记住的时候他并不是写日记，而是在记忆文件夹下随便创建一个文档，这样很快就乱了。我曾经花两天时间带着他整理内务
### 他的笔记
这是我自己的方法，让他建立一个 notes 文件夹，把一些正经的事情记在里面，这样起码做了一个简单的归类，找的时候方向性也更明确一点。
但是它自带的搜索并不是我们想象中的向量检索，而是针对关键词匹配，虽然他会去尝试一些相近的关键词但是准确性还是非常低的，主要是我们对于同一件事情多次的表述可能区别很大。
所以我设置他每天晚上去整理笔记，整理的方法如下：
- 对笔记内容进行信息提取
- 对每条提取的信息添加标签
- 标签优先从已有标签列表中进行选择（避免出现含义非常相近的同类标签）
- 如果确实需要添加新标签同时将标签加入已有标签列表
- 将提取后的内容附在该篇笔记的末尾
- 将笔记的文件名后面加入\_indexed
这样就有了一个比较明确的标签体系，需要的时候可以通过标签进行检索，相对准确性和速度都有所提升。
### 知识库
在主帖中已经说到，让他拉取官方文档和技能文档用于检索。当然你也可以放入其他文档作为它的知识库。
但如果文件数量比较大，最好还是安装一些专用的检索工具来进行组织。
* * *
这样组合下来并不能够让他不会忘记事情，但起码需要的时候能够让他尽快找到你需要的信息。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 9 日 01:04 UTC](https://meta.appinn.net/t/topic/81432/4 "2026-02-09T01:04:50Z")
## 能做什么
它比较偏向于命令行，当然也可以透过各种工具来进行自动化操作。
它可以比较稳定的去执行一个工作流，如果工作流比较长，可以通过定时器去不断触发保证他完成。
因为它是人工智能所以它可以比较灵活的去处理一些信息。
比如：
### Hacker news
久闻大名，但我真看不懂，确实可以通过翻译，但是铺天盖地的新闻我自己去筛选，又很难找到喜欢的信息。
让他去读取 RSS，进行筛选，然后将筛选的结果翻译出来，推送给你。
这里的真正重点其实在于筛选，我们的口味并不是单纯的几个分类或者标签就可以概括的，说一个科技新闻就能概括我的兴趣吗？其实科技新闻中有很多内容我是不喜欢看的，因为非常技术非常硬核的东西我看不懂，我只关心哪家大厂又出了新模型，哦哟哟好厉害！（吃瓜群众嘴脸）但是这样的需求有时候很难通过一个代码形式的过滤器来进行筛选。但是 AI 就非常适合做这件事情。我发现设置好以后他筛选的结果基本都符合我的口味。
这个调试好以后还可以逐渐的去增加更多的新闻源，这样就有了一份属于自己的专属定制报纸。这个体验感我觉得是颠覆级别的，相对于过去自己对着 RSS 里面虽然是自己订阅的，但依然需要进行筛选，找到自己爱看的内容的体验。
### 面板更新
很多人都让他自己给自己制作了一个控制面板，来展示各种状态。比如我会让他展示每次心跳（cron）的状态，以及他整理出来的新闻。写这样一个简单的小网页对大多数模型来说实在是太轻松了。
但最好你能一次说清楚所有需求，而不是一点一点增加需求让他改来改去。
然后其实也有一些现成的选择，比如 Sun-panel 其实提供了完整的 Api，所以你可以让他去管理更新上面的各种卡片，来展示你需要的信息。差不多只需要把文档发给他，然后设置好用来连接的 token，然后就是制定各种更新规则，对设定进行固化，设定触发条件。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 10 日 01:37 UTC](https://meta.appinn.net/t/topic/81432/5 "2026-02-10T01:37:55Z")
## Nanobot
安装并跑通了 nanobot，我觉得可能也没有多大区别。
仔细想想，这类工具又有哪些能力呢？本质不过是和 AI 聊天罢了。聊天之外，对于 AI 来说全都是工具调用。而最主要的一个能力，就是运行命令的能力，只要有这个能力，其实其他的功能它都可以自己去想办法实现。
然后自然会加上读写、修改文件这类常用的工具。但你会发现，如果这些工具不可用，AI 会自己用运行命令的能力去解决。
创建子智能体去并行运作，对于 AI 来说，也是工具的调用吧。
至于技能，就是通过提示词来实现工具的调用，或者直接用提示词对 AI 进行一些约束。
所以两三千行代码实现一个聊天和工具调用的框架，确实合理，没啥毛病。剩下主要还是看 AI 自身的能力。
感觉目前对于全新接触的用户，我可能更加推荐 nanobot。简单稳定，更容易掌控。
OpenClaw 的一个问题是，无论你用什么模型，都有一定可能性把配置改得面目全非。
Nanobot 现在支持了更多国内聊天工具的接入。在安装上虽然算不上一键安装但是使用官方的指令按步骤操作也没啥问题。配置起来也没有那么麻烦，初始化之后自己简单修改它的配置文件就行了它的配置文件写的层级比较少，所以非常容易读懂。
唯一的坑可能就是在指定模型的时候并不需要带上提供商的名字，看起来他似乎认为你只会配置一个提供商，或者提供商之间模型的名字不会产生冲突。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 10 日 04:35 UTC](https://meta.appinn.net/t/topic/81432/6 "2026-02-10T04:35:22Z")
## 上下文策略
我比较喜欢 nanoBot 这种上下文策略：
- 整个对话记录会同步写入硬盘，这样几乎不存在对话或者信息因意外丢失的状况
- 但每次向AI发送请求只携带最近 50 次的信息记录，这样相对更加节省上下文
- 没有强制的上下文压缩
虽然模型每次接收到的不是完整信息但是基本足够用来解决眼下的问题，而且可以一直聊下去，不用考虑上下文压缩的问题。并且在有需要的情况下可以让 AI 自己读取硬盘中的对话文件，来检索对话中的任何信息。
如果你真的希望ai记住某些东西应该让他将设定存入长期记忆。
我觉得这种设计方案平衡性比较好。
OpenClaw 那种强制压缩上下文的方案，就需要自行去考虑并设定对话中信息的及时保存。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 11 日 00:24 UTC](https://meta.appinn.net/t/topic/81432/7 "2026-02-11T00:24:40Z")
## Token节省术
> 说个题外话，逛闲鱼的时候看到了一条非常有意思的评价： **这家 token 很好用** 。感觉像是量词变成了名词，反正类似于这个手机拍照像素很好（
直接上干货：（强烈建议电脑端阅读）
```markdown
┌─────────────────────────────────────────────────────────────────┐
│ 分次调用 (Sequential) │
│ 低效 · 多次请求 · 高延迟 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 用户提问 │───→│ 大模型 │───→│ 调用工具 │───→│ 返回结果 │ │
│ │ │ │ 思考中 │ │ A │ │ A │ │
│ └─────────┘ └────┬────┘ └─────────┘ └────┬────┘ │
│ ▲ │ │ │
│ │ └──────────────────────────────┘ │
│ │ ↓ │
│ │ ┌─────────┐ ┌─────────┐ │
│ │ │ 大模型 │───→│ 调用工具 │ │
│ │ │ 再思考 │ │ B │ │
│ │ └────┬────┘ └─────────┘ │
│ │ │ │ │
│ │ └───────────┘ │
│ │ ↓ │
│ │ [重复 N 次...] │
│ │ ↓ │
│ │ ┌─────────┐ ┌─────────┐ │
│ │ │ 大模型 │───→│ 调用工具 │ │
│ │ │ 再思考 │ │ Z │ │
│ │ └────┬────┘ └─────────┘ │
│ │ │ │ │
│ └─────────────────────────┴───────────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ 最终答案 │ │
│ └─────────┘ │
│ │
│ 📊 消耗统计: │
│ ├─ 请求次数: N+1 次 (工具数量 + 最终回答) │
│ ├─ 上下文重复: 每次请求都携带完整历史 │
│ ├─ Token 浪费: ████████████████████ 高 │
│ └─ 总延迟: T₁ + T₂ + ... + Tₙ (串行累积) │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 集体调用 (Batch/Parallel) │
│ 高效 · 单次请求 · 低延迟 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────────────┐ │
│ │ 用户提问 │───→│ 大模型 │───→│ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │ │ 思考中 │ │ │工具A│ │工具B│ │工具Z│ │ │
│ └─────────┘ └────┬────┘ │ └─────┘ └─────┘ └─────┘ │ │
│ ▲ │ └───────────┬───────────────┘ │
│ │ │ │ │
│ │ │ ┌─────────────┐ │
│ │ │ │ 并行执行 │ │
│ │ │ │ 等待全部 │ │
│ │ │ │ 结果返回 │ │
│ │ │ └──────┬──────┘ │
│ │ │ │ │
│ │ │ ┌─────────────────────────────────┐ │
│ │ └───→│ 结果A + 结果B + ... + 结果Z │ │
│ │ │ (单次上下文，整合所有信息) │ │
│ │ └─────────────────┬─────────────────┘ │
│ │ │ │
│ └─────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ 最终答案 │ │
│ └─────────┘ │
│ │
│ 📊 消耗统计: │
│ ├─ 请求次数: 2 次 (计划调用 + 最终回答) │
│ ├─ 上下文传输: 仅传输一次 │
│ ├─ Token 效率: ████████░░░░░░░░░░░░ 高 │
│ └─ 总延迟: max(T₁, T₂, ... Tₙ) (并行取最大) │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 关键差异对比 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 维度 分次调用 集体调用 │
│ ───────────────────────────────────────────────────────── │
│ 请求次数 N+1 次 2 次 │
│ 网络开销 高 (多次握手) 低 (单次往返) │
│ Token 消耗 历史重复 × N 次 历史仅传输 1 次 │
│ 延迟特性 累加延迟 并行取最大 │
│ 上下文长度 逐渐膨胀 可控且紧凑 │
│ 适用场景 工具依赖链式 工具相互独立 │
│ │
│ 💡 优化建议: 除非工具B依赖工具A的结果，否则优先使用集体调用 │
│ │
└─────────────────────────────────────────────────────────────────┘
```
比如读取文件夹下所有文件，如果读取一个思考一下然后决定读取下一个再思考一下……100 个文件就 100 多个请求，而且每个请求都是要携带上下文的。
但是如果换成他使用指令直接从这 100 个文件中搜索他想要的信息，即便为了保证效果中间更换几次关键词，产生的请求次数和消耗的 token 也是要比上一种方法小很多的。
但有时候如果你不强调 AI 可能就会按照第1种方法去工作，而有一些常用的操作，为了保证稳定，应该先让 AI 写成脚本。
我也忽然开始理解为什么某些模型很喜欢写脚本，如果要对 5 个文件进行修改，逐次修改至少是5个请求，但是如果他分析出要修改的位置，写一个脚本。然后执行这个脚本可能就两次请求。（当然那种修改一个文件也非要写个脚本的我，还是想吐槽，写完这句话再想想，也许他对那一个文件同时修改了几个地方呢……看起来以后吐槽也需要深思熟虑了）
所以计费方式无论是请求次数还是 token 的消耗量，这种优化都是很有必要的。至于输出文字的多少，反倒相对来说占比并不大。
然后如果过度强调严谨，也会增大请求次数，比如我为了避免他的幻觉所以要求他对于任何一个文件都要先读取，而不是凭着他那不靠谱的记忆来给我讲解。还有修改写入文件之后要做校验，避免实际写入失败但却向我汇报成功的状况。然后差不多工作量就翻倍了。
然后如果主智能体自己操作，它携带的是完整上下文，当然可能对问题需求理解的更加透彻，但是每次请求的 token 消耗量也是更大的，而如果交给子智能体去操作，子智能体获得的只是主智能体交给他的提示词，这就减少了很多不必要的消耗。
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 11 日 00:38 UTC](https://meta.appinn.net/t/topic/81432/8 "2026-02-11T00:38:45Z")
## 心跳和 Cron
这两个居然不是一个概念，我混淆了很久。
心跳是定时触发的，用来保证它连续工作的，心跳的时间间隔是可以自己设定的，也可以关掉。它的默认操作就是读取工作空间的那个心跳文档，根据文档的内容进行操作。
所以如果你有一个需要连续执行的任务，就可以在那个文档中写入任务要求，并在其中更新任务进度，这样每次心跳都会将任务推进一些。借着这种方式让他表现的更像一个自己在后台默默工作的机器人。
Cron 是定时器，你可以设置任意数量的定时器，比如定时提醒之类的都可以通过它触发。
可以看出这两者是可以混用的，但似乎心跳的设置并没有显示在 Cron 的界面中，所以这里需要稍微注意一下
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 11 日 00:57 UTC](https://meta.appinn.net/t/topic/81432/9 "2026-02-11T00:57:04Z")
## 它能做什么
说真的我也不是很清楚。我觉得有很多人都和我一样：在这些AI工具上感受到了生产力，但怎么把它变成真正的生产力，确实又有些迷茫。所以所有的人都在探索阶段。
如果放在特定场景下它的工作效率绝对是要比人高很多的，而且也确实很有可能实现自动化执行。即便使用最昂贵的订阅套餐，再加上设备的成本，性价比仍然比雇佣于人类员工更高。所以如果我是老板，以前需要 5 个人做的工作，现在我可能更倾向于雇一两个人然后再加几台这样的 AI 员工。 AI 员工又便宜又稳定，不容易有什么大的变动，而且未来工作交接也比较容易。
* * *
但在实际使用中，我只是想让他每天抓取一下hn的新闻，然后筛选，将筛选的结果翻译过来给我看。我用的模型不算差，但调来调去这个工作流也没跑好。遇到的坑非常多：
- 像上面的定时器问题
- 筛选究竟是使用程序筛选还是让 AI 进行筛选，当然 AI 筛选的灵活性会更好，但是如果组织能提参与工作，可能这段时间和他说话就会被卡住，好久才反应。而如果让子智能体去做这件事情，虽然很合理，但工作效果非常依赖于主智能体传递进去的提示词，而有一些模型在这个位置非常偷懒，差不多相当于`在这一步调用子智能体，具体提示词：（略）`，这样的情况下就别指望得到什么可用的结果了。
- 翻译工作也是同样的状况
- 还要考虑如何让他避免重复推荐，虽然他肯定能给出一个方案，但是后续能不能保证他稳定的按照这个方案去执行，在哪里进行约束，如何约束也是问题。
- 本来我希望让他将最后的结果更新到一个网页上，方便我随时阅读。但是他又常常忘记更新到网页上的方法，于是写了对应脚本，又忘记了脚本的使用方法……所以又写了脚本的使用文档
总而言之坑非常多。
当然看看这一两天网络上流传的测试 AI 的那个问题：
> 我想去洗车，我家距离洗车场 50 米，我是应该走着去，还是开车去。
一众 AI 异口同声：走着去（你们别去测试了，现在大部分 AI 都修复了这个笨蛋问题）
总之这很容易说明，现在很强大的 AI 其实还是个笨蛋，笨蛋能干一些活就不错了，也不要指望太多。（当然可以期待大模型越来越聪明，毕竟现在发展这么快，确实还是很值得期待的
* * *
现在机器人跳舞很火爆，谁能想到机器人大卖是这么个原因呢，但总之，机器人和 AI 抢人类的工作岗位已经是必然的了，留给人类的只有机器人“驾驶员”这个岗位，但显然不再需要过去那么多人了。
有人问你们折腾小龙虾消耗了那么多 token 它的意义在哪里呢？如果只就眼下看，我折腾了好几天连个抓取新闻的流程都没跑利索，那确实毫无意义了。可是我们在学习驾驶的时候，花了那么多油钱只是在封闭场地里一圈一圈的转，意义又是什么呢？
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@dms](https://meta.appinn.net/u/dms)
#### 发布日期： [2026 年2 月 11 日 01:55 UTC](https://meta.appinn.net/t/topic/81432/10 "2026-02-11T01:55:58Z")
## 能做什么
我觉得下面这张图应该非常能够说明当前的状况，起因是 [draw.io](http://draw.io) 发布了一个官方的mcp：@drawio/mcp，我就是装上试一试，然后花了将近两毛钱后来如下一张图：
- 乍一看一团乱麻，这画的都什么玩意儿啊
- 细一看只有上面的标注字体太大了，其他的像周边信息，以及键盘的键位画的问题都不大
- 当然标注文字和键盘按键是混排的，确实不太好调整，但这也只是相对于人手工调整来说
所以状况就是：
- 做了吗？做了
- 正确吗？好像也差不多
- 能用吗？不能用
- 能补救吗？人工补救很难，可能约等于重做
但潜力呢？比如一年以后……不敢想，真的不敢想
> [!important] 为我家的小龙虾求点口粮
> ｡°(°¯᷄◠¯᷅°)°｡
> Token 消耗量巨大，小龙虾要断粮了
> 希望大家留点猫粮 [投喂小龙虾](https://afdian.com/a/daomishu)
---
### 作者：  [@a523084467](https://meta.appinn.net/u/a523084467)
#### 发布日期： [2026 年2 月 11 日 02:15 UTC](https://meta.appinn.net/t/topic/81432/11 "2026-02-11T02:15:14Z")
期待更强的AI~无需调教的那种。前天试用了一下codex5.3，直接用还是不尽人意