1. 从零开始为什么我要做一个AI智能体1.1 项目缘起ClawdBot这个奇怪的名字把人生第一个AI智能体跑通的那一刻说实话比当年第一次写出Hello World还激动。它叫ClawdBot后来我习惯叫它MoltBot。名字的由来很随意——Clawd是我当时给某个测试账号起的昵称Molt则是“换羽”的意思代表这个项目会不断推翻重来。没想到这个“随便起的名字”最后成了我连续折腾了两个多月的核心项目。ClawdBot做的事情其实很简单每天早上定时抓取几个信息源汇总成一份简报推送给我能在群里回答一些被问过无数遍的重复问题还能在我说“帮我查一下今天有没有重要会议”时自动去翻日历并给出答复。但就是这样一个“看起来只是把聊天机器人加了个定时器”的东西让我真正明白了AI智能体和聊天机器人之间的界线在哪里。这个项目适合谁看两类人。第一类是完全没接触过智能体开发、想从零跑通一个真实项目的新手第二类是已经写过一些接口调用脚本、但还没想清楚“智能体到底该怎么设计”的开发者。我会把从构思、设计、写代码到踩坑的完整过程都写出来包括那些网上教程很少告诉你的细节。1.2 智能体到底是个什么东西在动手之前我先把概念捋了一遍。普通的聊天机器人本质是“输入一句话输出一句话”它的能力边界就是模型本身的常识和上下文窗口。而智能体至少要具备三个特征有目标、能调用工具、能根据环境反馈调整下一步行动。举个生活化的例子。聊天室里的自动回复机器人就像便利店收银员——你问什么他答什么超出他的商品范围就只能说“不好意思没有”。而智能体更像一个随叫随到的私人助理——你说“帮我把这周的日程理一下”他不仅知道要去哪里拿日程数据还知道如果发现冲突要按什么规则处理最后把结果整理成一封你能直接看的邮件发给你。ClawdBot的定位就介于这两者之间。我不需要它像Agent那样完全自主决策但至少要做到接收任务、拆解任务、调用外部接口、组合结果、输出答案。这个“目标感”差一点做出来的东西就是玩具。2. 整体设计ClawdBot的架构与思路拆解2.1 需求定位我要它帮我干什么很多人做智能体第一步就去研究LangChain、研究各种框架结果代码写了一堆最后却没想清楚智能体到底解决什么问题。我做ClawdBot的第一件事是在便签上写下了三个我要解决的痛点。第一个痛点是信息聚合。我每天要花大概二十分钟浏览几个固定的技术社区和新闻站点然后自己在脑子里汇总出“今天发生了什么”。这件事完全可以让智能体替我干。第二个痛点是被重复问题轰炸。我们几个朋友有个技术交流群每周都会有人问“这个环境怎么配”“那个报错怎么解决”同一个答案我复制粘贴到快吐了。第三个痛点是个性化提醒。我的会议和时间安排散落在不同工具里靠手机上的闹钟提醒实在不够智能。这三个需求决定了ClawdBot不能只是一个“问一句答一句”的聊天界面。它需要有调度核心、信息抓取模块、消息推送通道还要有能够被模型调用的工具函数。我给它画了一条很粗的流程线用户指令进入调度器调度器理解意图后决定调用哪个工具工具返回结果后再由调度器组织语言输出。值得一提的是这个架构我刻意没有在一开始就引入多智能体协作。原因很简单第一版如果就跑在复杂架构上出了问题你根本不知道是模型的问题、工具的问题还是流程编排的问题。先把单智能体跑通后面再加东西这是我最想提醒新手的一点。2.2 技术选型模型、框架与运行环境怎么选技术选型我纠结了很久。ClawdBot的目的是跑通真实场景不是比拼用了多fancy的框架所以我的原则是能用简单方案解决就不用重型框架。模型选型上我用了国内可稳定调用的大模型API服务。为什么不用本地模型因为我的电脑只是一台普通笔记本本地跑大模型的推理速度实在感人而且显存有限用了就干不了别的了。调用API虽然受网络和配额限制但对于个人项目来说成本完全可以接受免费额度都够我折腾很久。框架方面我一开始就决定不直接用Agent框架而是用最基础的Python加上一个异步HTTP客户端。原因是我想把整个流程吃透而不是被框架圈住。后来实际写下来发现核心调度逻辑其实只需要几百行代码大部分时间花在调试提示词和处理各种接口返回格式上。运行环境我选了一台带公网IP的云服务器配置只要2核心4G内存就足够。这里有个很重要的理由如果ClawdBot跑在我自己的电脑上一旦电脑休眠或者断网整个智能体就“失联”了。放在服务器上之后我只需要通过消息推送接口和它交互它就能全天候运行。实际上ClawdBot的技术栈最后就四块东西Python 3.10、大模型API、消息推送接口、定时任务模块。没有数据库没有消息队列没有微服务。这就是我想传达的一个态度人生第一个智能体先把它做“小”做“完整”再做“大”。3. 一步步实现从空目录到能跑起来的第一个版本3.1 搭建项目骨架与核心调度逻辑我习惯用一句话描述系统边界ClawdBot是一个“感知-决策-行动”的闭环。感知层接收用户指令或定时信号决策层调用大模型理解意图行动层执行具体函数比如抓网页、读日历、发消息。下面是当时项目初始目录的样子。clawdbot/ ├── main.py ├── config.py ├── core/ │ ├── scheduler.py │ └── engine.py ├── tools/ │ ├── fetcher.py │ ├── calendar.py │ └── notifier.py └── prompts/ └── system_prompt.mdmain.py是入口负责启动调度器core/engine.py是核心循环负责把大模型、工具函数和上下文串起来tools/下面放各种工具函数prompts/里放系统提示词。是不是看起来太像普通后端项目确实。智能体的骨架本质上就是一个后端服务只是它的“业务逻辑”不是预先写死的if/else而是由模型动态生成。核心调度逻辑我写得很克制核心就是一个工具注册表加一个消息循环。下面是我简化后的代码保留了关键部分import json import asyncio # 工具注册表所有可被模型调用的工具都注册在这里 TOOL_REGISTRY {} def register_tool(name, description, handler): TOOL_REGISTRY[name] { description: description, handler: handler, } async def run_conversation(user_input, messages): # 1. 组装请求消息 messages.append({role: user, content: user_input}) # 2. 调用大模型带上工具定义 response await call_llm( messagesmessages, tools[{name: n, description: d[description]} for n, d in TOOL_REGISTRY.items()] ) # 3. 判断模型是否请求调用工具 if response.get(tool_calls): for call in response[tool_calls]: tool_name call[function][name] args json.loads(call[function][arguments]) result await TOOL_REGISTRY[tool_name][handler](**args) messages.append({ role: tool, name: tool_name, content: json.dumps(result, ensure_asciiFalse) }) # 多次迭代直到模型不再请求调用工具 return await run_conversation(, messages) return response[content]这个循环你可能觉得眼熟它就是几乎所有智能体框架的底层逻辑。手动写一遍的价值在于我知道模型返回tool_calls长什么样知道工具执行结果应该以role“tool”的消息用什么样的格式回填也知道什么时候该终止循环。这些细节一旦出了问题用框架根本不知道怎么排查。启动后我的第一个成功用例是让ClawdBot调用工具查询当前时间。我输入“现在几点了”模型没有直接说时间而是构造了call_tool({name: get_current_time})工具返回时间戳后模型再把它组织成自然语言。那一刻我才真正意识到它不是“查”到了时间而是“用”了一个工具拿到了时间。这个区别就是智能体的精髓。3.2 让Bot真正“智能”提示词工程初体验工具调用是骨架提示词是灵魂。ClawdBot如果只靠默认提示词它的表现就是一个什么都会一点但什么都不精的聊天机器人。我在system_prompt.md里写得很细包括角色定位、工作流程、工具使用守则、语气风格。下面是我后来整理出的一个核心版本你是ClawdBot一个以效率和准确为先的个人智能助理。 工作守则 1. 如果用户的需求涉及查询实时信息必须先调用对应工具获取事实再基于工具结果回答。严禁直接编造。 2. 工具调用失败时如实告知用户失败原因并且给出建议不要强行圆场。 3. 回答保持简洁。能用三句话说清楚的事不要写十句。 4. 如果用户请求不明确先提出一个澄清问题再行动。 5. 涉及日程类操作默认按用户的时区解释所有时间。这段提示词看起来简单但每一句都是我踩坑踩出来的。比如第一条最初我没有强调“严禁编造”结果它在我问天气的时候信誓旦旦地告诉我“今天晴转多云”实际上那天下着暴雨因为它根本没有调用天气工具。这种“一本正经地胡说八道”是智能体落地最大的敌人。还有一次我让它帮我查某篇技术文档它直接基于记忆给出了一个不存在的接口名。我加了第一条之后这种情况明显减少。提示词不是写得越华丽越好关键是写清楚“什么时候做什么、什么时候不做什么”。这也是我想强调的一点工具定义和提示词是配套的工具告诉模型“你能做什么”提示词告诉模型“你应该怎么做”。3.3 定时任务与消息推送它开始主动找我了ClawdBot真正从“玩具”变成“工具”是它开始主动找我的那一刻。我给它配了一个每天早上九点执行的定时任务——抓取指定站点更新汇总成简报发到我的消息软件上。第一次早上收到它推送的简报时我甚至恍惚了一下感觉像多了个实习生。定时调度我用的是系统级的crontab没有在代码里写一个常驻循环。理由很简单crontab本身是成熟的进程管理器如果程序崩溃了下一次到点它还会重新拉起进程。相比之下如果自己写asyncio循环就得多考虑守护进程、崩溃恢复这些问题。# 每天早上九点执行简报任务 0 9 * * * cd /home/user/clawdbot /usr/bin/python3 main.py --task daily_report logs/daily.log 21日志重定向也是我一开始就加上的。跑智能体没有日志出问题连猜都没法猜。main.py里加了一个--task参数让同一个入口既能执行定时任务也能启动交互式对话服务。这个设计让测试变得很方便——我不用整天跑聊天接口直接运行一次任务就能看到整个管线是否正常。消息推送这块我接的是通用的Webhook机器人。原理很简单往一个URL POST一段JSON消息就会出现在我的手机上。推送代码本身很简单但有一个注意点一定要做频率控制否则一旦某个工具循环出错可能一分钟给你推上百条消息。我后来在调度器里加了一个“每日推送上限”的计数器达到上限就停止推送。4. 踩坑实录新手做智能体最容易翻车的五个地方4.1 上下文管理失控对话超过窗口直接报错第一个大坑是上下文溢出。ClawdBot运行一段时间后我发现在长对话场景下API开始报错提示输入超出最大token数限制。一开始我的处理方式是直接把所有消息一股脑塞给模型想着“模型不是有上下文窗口吗”但实际上每轮使用的token是累加的累积到某个上限就会崩。解决方案是给消息列表加一个“滑动窗口摘要”策略当消息条数超过10轮我会把最早的一部分对话压缩成一段摘要替换掉原始消息。注意摘要不是自己拿大模型生成而是让调度器提取关键词和结论控制摘要本身的长度。这段逻辑大概只有三十行但直接决定了智能体能不能进行持续较长的会话。4.2 模型输出不稳定同一个问题答案天差地别第二个坑是输出不稳定。模型参数里有temperature如果你不调默认值是随机的。ClawdBot早期回答同一道知识性问题两次答案措辞完全不同甚至有一次数据引用错了。后来我把工具调用相关的请求temperature设为0.2纯粹闲聊类的才放开到0.7。这个区分特别重要涉及事实和工具答案应该尽量确定涉及创意、标题、文案可以保留一定随机性。如果没有这个区分你会觉得智能体像一个情绪不稳定的人。另外我还会在工具调用请求里把top_p设为0.8减少低概率分支的采样。这一步很小但效果立竿见影。4.3 定时任务挂掉进程崩溃后不会自愈第三个坑来自异常处理不够充分。有一次我在日志里发现连续两天的早报都没有推送排查后发现是其中一个信息源网站改了HTML结构抓取函数抛了一个超时异常整个定时任务直接中断。因为crontab的配置是“如果前一个进程还在运行后续任务不执行”所以我看到的现象就是“智能体彻底失联”。我做了两层防抖一是给所有工具函数加上超时和重试逻辑二是调度器顶层包了一个try...except任何异常都先写入日志不会被裸奔抛出导致进程退出。再后来我在推送函数里加了一个/status心跳命令ClawdBot每隔六个小时给自己发一条“我还活着”的消息。这个设计虽然土但真的管用。4.4 API调用限流免费额度瞬间耗尽第四个坑是限流和额度。ClawdBot刚上线时我在群聊里开放了测试入口结果半天不到免费额度就消耗殆尽。我看了一下日志发现一个用户连续重发了二十多条消息其中很多都是重复内容每次触发都会完整走一遍大模型调用。补救措施包括同一用户一分钟内最多处理3条消息、相同内容5分钟内不重复处理、每个任务输出长度限制在512个token以内。额度管理看似是资源问题实际是产品问题——你必须在设计上就克制对模型的调用而不是依赖用户自觉。4.5 隐私与安全不要把钥匙写死在代码里最后一个是安全习惯。一开始我在config.py里直接写了大模型的API密钥结果有一次想分享项目截图给朋友差点就把密钥发出去。后来我把所有密钥放到环境变量里用.env文件管理并把.env加入了.gitignore。还有一点是工具权限要最小化。ClawdBot刚学会调用日历工具时我给了它全部日程的读写权限。后来发现它确实能“帮我”加日程但也会在理解错指令时删掉不该删的东西。我不断缩小工具的操作范围——现在它只能读日程、不能删除任何修改类操作都要二次确认。这个教训可能只值一行代码但价值极高。5. 让ClawdBot更进一步升级为MoltBot的经验5.1 从单轮到多智能体ClawdBot稳定运行两周后我开始觉得单智能体的形式有瓶颈。比如我要让它同时完成“收集信息”和“筛选重要信息”两件事在单模型里全部交给提示词控制系统提示词已经膨胀到两千多字效果反而下降。所以我在代号换为MoltBot时做了一次大重构。这次重构最重要的变化是拆成了“情报采集员”和“简报编辑”两个角色。采集员只负责调用抓取工具把原始内容整理成结构化条目编辑再根据预设的关注点筛选和排序。两个角色共用同一个模型API但通过不同的系统提示词隔离职责。说实话这个“多智能体”还没有达到让多个Agent自由对话、互相协作的程度更像是一个流水线。但体验上的提升是明显的每个角色的职责单一提示词更短工具调用准确率反而提高了。如果你也想做多智能体我的建议是从“拆职责”开始而不是一上来就搞复杂的Agent通信协议。5.2 知识库接入让智能体不再“临时抱佛脚”MoltBot的第二个升级点是知识库。早期它回答技术类问题完全靠模型的记忆一旦问到我之前处理过的某个具体项目的细节它就只能瞎编。后来我接了一个轻量级向量数据库把我整理过的笔记、文档切块后做成了索引。用户在群里问了相关问题MoltBot先从知识库检索相关内容再把检索结果和问题一起交给模型组织答案。这个检索增强生成的结构并不复杂但需要特别小心检索质量。有一次它把我一篇关于“数据库备份”的笔记当成“磁盘扩容”的参考回答闹了个大笑话。解决办法是给知识库条目加标签和置信度阈值检索得分低于阈值时宁可告诉用户“没找到”也不要硬答。5.3 人机协作的边界智能体不是用来“代替思考”的最后我想分享一个认知层面的收获。做ClawdBot的过程中我最兴奋的时候是它能自动跑通流程但我最害怕的时候也是它过于“主动”。当它开始基于自己的推断删除日程、把不确定的事情当成确定的事情汇报时我意识到一个问题智能体作为早期系统它的核心价值是帮人节省重复劳动而不是替人做判断。所以我在MoltBot里增加了一个“置信度标注”机制。当模型判断某个操作存在不确定性时它必须在回答里明确写“我不完全确定以下是依据”。这个机制不复杂但非常有效——它强制模型在模糊场景下承认自己的局限。真正的智能从知道自己不知道什么开始。我在实际使用中一个深刻的体会是人生第一个AI智能体成功的关键不在模型多先进而在于你有多了解自己要做的那件事。当你把一个流程拆得足够细你会发现让AI接管其中60%的环节并没有那么难难的是判断剩下40%怎么处理。ClawdBot教会我的不只是怎么调用大模型、写工具函数更是怎么在一个模糊问题面前理清边界。如果你也想做自己的第一个智能体不要一开始就追求无所不能。先让它帮你做一件最烦的重复事再把范围慢慢扩大。这个项目后续我还在继续扩展比如加入语音交互、接入更多外部数据源但所有升级都建立在最初那个朴素的闭环上。你人生中第一个智能体应该也从这样一个极小的闭环开始。
1. 从零开始为什么我要做一个AI智能体1.1 项目缘起ClawdBot这个奇怪的名字把人生第一个AI智能体跑通的那一刻说实话比当年第一次写出Hello World还激动。它叫ClawdBot后来我习惯叫它MoltBot。名字的由来很随意——Clawd是我当时给某个测试账号起的昵称Molt则是“换羽”的意思代表这个项目会不断推翻重来。没想到这个“随便起的名字”最后成了我连续折腾了两个多月的核心项目。ClawdBot做的事情其实很简单每天早上定时抓取几个信息源汇总成一份简报推送给我能在群里回答一些被问过无数遍的重复问题还能在我说“帮我查一下今天有没有重要会议”时自动去翻日历并给出答复。但就是这样一个“看起来只是把聊天机器人加了个定时器”的东西让我真正明白了AI智能体和聊天机器人之间的界线在哪里。这个项目适合谁看两类人。第一类是完全没接触过智能体开发、想从零跑通一个真实项目的新手第二类是已经写过一些接口调用脚本、但还没想清楚“智能体到底该怎么设计”的开发者。我会把从构思、设计、写代码到踩坑的完整过程都写出来包括那些网上教程很少告诉你的细节。1.2 智能体到底是个什么东西在动手之前我先把概念捋了一遍。普通的聊天机器人本质是“输入一句话输出一句话”它的能力边界就是模型本身的常识和上下文窗口。而智能体至少要具备三个特征有目标、能调用工具、能根据环境反馈调整下一步行动。举个生活化的例子。聊天室里的自动回复机器人就像便利店收银员——你问什么他答什么超出他的商品范围就只能说“不好意思没有”。而智能体更像一个随叫随到的私人助理——你说“帮我把这周的日程理一下”他不仅知道要去哪里拿日程数据还知道如果发现冲突要按什么规则处理最后把结果整理成一封你能直接看的邮件发给你。ClawdBot的定位就介于这两者之间。我不需要它像Agent那样完全自主决策但至少要做到接收任务、拆解任务、调用外部接口、组合结果、输出答案。这个“目标感”差一点做出来的东西就是玩具。2. 整体设计ClawdBot的架构与思路拆解2.1 需求定位我要它帮我干什么很多人做智能体第一步就去研究LangChain、研究各种框架结果代码写了一堆最后却没想清楚智能体到底解决什么问题。我做ClawdBot的第一件事是在便签上写下了三个我要解决的痛点。第一个痛点是信息聚合。我每天要花大概二十分钟浏览几个固定的技术社区和新闻站点然后自己在脑子里汇总出“今天发生了什么”。这件事完全可以让智能体替我干。第二个痛点是被重复问题轰炸。我们几个朋友有个技术交流群每周都会有人问“这个环境怎么配”“那个报错怎么解决”同一个答案我复制粘贴到快吐了。第三个痛点是个性化提醒。我的会议和时间安排散落在不同工具里靠手机上的闹钟提醒实在不够智能。这三个需求决定了ClawdBot不能只是一个“问一句答一句”的聊天界面。它需要有调度核心、信息抓取模块、消息推送通道还要有能够被模型调用的工具函数。我给它画了一条很粗的流程线用户指令进入调度器调度器理解意图后决定调用哪个工具工具返回结果后再由调度器组织语言输出。值得一提的是这个架构我刻意没有在一开始就引入多智能体协作。原因很简单第一版如果就跑在复杂架构上出了问题你根本不知道是模型的问题、工具的问题还是流程编排的问题。先把单智能体跑通后面再加东西这是我最想提醒新手的一点。2.2 技术选型模型、框架与运行环境怎么选技术选型我纠结了很久。ClawdBot的目的是跑通真实场景不是比拼用了多fancy的框架所以我的原则是能用简单方案解决就不用重型框架。模型选型上我用了国内可稳定调用的大模型API服务。为什么不用本地模型因为我的电脑只是一台普通笔记本本地跑大模型的推理速度实在感人而且显存有限用了就干不了别的了。调用API虽然受网络和配额限制但对于个人项目来说成本完全可以接受免费额度都够我折腾很久。框架方面我一开始就决定不直接用Agent框架而是用最基础的Python加上一个异步HTTP客户端。原因是我想把整个流程吃透而不是被框架圈住。后来实际写下来发现核心调度逻辑其实只需要几百行代码大部分时间花在调试提示词和处理各种接口返回格式上。运行环境我选了一台带公网IP的云服务器配置只要2核心4G内存就足够。这里有个很重要的理由如果ClawdBot跑在我自己的电脑上一旦电脑休眠或者断网整个智能体就“失联”了。放在服务器上之后我只需要通过消息推送接口和它交互它就能全天候运行。实际上ClawdBot的技术栈最后就四块东西Python 3.10、大模型API、消息推送接口、定时任务模块。没有数据库没有消息队列没有微服务。这就是我想传达的一个态度人生第一个智能体先把它做“小”做“完整”再做“大”。3. 一步步实现从空目录到能跑起来的第一个版本3.1 搭建项目骨架与核心调度逻辑我习惯用一句话描述系统边界ClawdBot是一个“感知-决策-行动”的闭环。感知层接收用户指令或定时信号决策层调用大模型理解意图行动层执行具体函数比如抓网页、读日历、发消息。下面是当时项目初始目录的样子。clawdbot/ ├── main.py ├── config.py ├── core/ │ ├── scheduler.py │ └── engine.py ├── tools/ │ ├── fetcher.py │ ├── calendar.py │ └── notifier.py └── prompts/ └── system_prompt.mdmain.py是入口负责启动调度器core/engine.py是核心循环负责把大模型、工具函数和上下文串起来tools/下面放各种工具函数prompts/里放系统提示词。是不是看起来太像普通后端项目确实。智能体的骨架本质上就是一个后端服务只是它的“业务逻辑”不是预先写死的if/else而是由模型动态生成。核心调度逻辑我写得很克制核心就是一个工具注册表加一个消息循环。下面是我简化后的代码保留了关键部分import json import asyncio # 工具注册表所有可被模型调用的工具都注册在这里 TOOL_REGISTRY {} def register_tool(name, description, handler): TOOL_REGISTRY[name] { description: description, handler: handler, } async def run_conversation(user_input, messages): # 1. 组装请求消息 messages.append({role: user, content: user_input}) # 2. 调用大模型带上工具定义 response await call_llm( messagesmessages, tools[{name: n, description: d[description]} for n, d in TOOL_REGISTRY.items()] ) # 3. 判断模型是否请求调用工具 if response.get(tool_calls): for call in response[tool_calls]: tool_name call[function][name] args json.loads(call[function][arguments]) result await TOOL_REGISTRY[tool_name][handler](**args) messages.append({ role: tool, name: tool_name, content: json.dumps(result, ensure_asciiFalse) }) # 多次迭代直到模型不再请求调用工具 return await run_conversation(, messages) return response[content]这个循环你可能觉得眼熟它就是几乎所有智能体框架的底层逻辑。手动写一遍的价值在于我知道模型返回tool_calls长什么样知道工具执行结果应该以role“tool”的消息用什么样的格式回填也知道什么时候该终止循环。这些细节一旦出了问题用框架根本不知道怎么排查。启动后我的第一个成功用例是让ClawdBot调用工具查询当前时间。我输入“现在几点了”模型没有直接说时间而是构造了call_tool({name: get_current_time})工具返回时间戳后模型再把它组织成自然语言。那一刻我才真正意识到它不是“查”到了时间而是“用”了一个工具拿到了时间。这个区别就是智能体的精髓。3.2 让Bot真正“智能”提示词工程初体验工具调用是骨架提示词是灵魂。ClawdBot如果只靠默认提示词它的表现就是一个什么都会一点但什么都不精的聊天机器人。我在system_prompt.md里写得很细包括角色定位、工作流程、工具使用守则、语气风格。下面是我后来整理出的一个核心版本你是ClawdBot一个以效率和准确为先的个人智能助理。 工作守则 1. 如果用户的需求涉及查询实时信息必须先调用对应工具获取事实再基于工具结果回答。严禁直接编造。 2. 工具调用失败时如实告知用户失败原因并且给出建议不要强行圆场。 3. 回答保持简洁。能用三句话说清楚的事不要写十句。 4. 如果用户请求不明确先提出一个澄清问题再行动。 5. 涉及日程类操作默认按用户的时区解释所有时间。这段提示词看起来简单但每一句都是我踩坑踩出来的。比如第一条最初我没有强调“严禁编造”结果它在我问天气的时候信誓旦旦地告诉我“今天晴转多云”实际上那天下着暴雨因为它根本没有调用天气工具。这种“一本正经地胡说八道”是智能体落地最大的敌人。还有一次我让它帮我查某篇技术文档它直接基于记忆给出了一个不存在的接口名。我加了第一条之后这种情况明显减少。提示词不是写得越华丽越好关键是写清楚“什么时候做什么、什么时候不做什么”。这也是我想强调的一点工具定义和提示词是配套的工具告诉模型“你能做什么”提示词告诉模型“你应该怎么做”。3.3 定时任务与消息推送它开始主动找我了ClawdBot真正从“玩具”变成“工具”是它开始主动找我的那一刻。我给它配了一个每天早上九点执行的定时任务——抓取指定站点更新汇总成简报发到我的消息软件上。第一次早上收到它推送的简报时我甚至恍惚了一下感觉像多了个实习生。定时调度我用的是系统级的crontab没有在代码里写一个常驻循环。理由很简单crontab本身是成熟的进程管理器如果程序崩溃了下一次到点它还会重新拉起进程。相比之下如果自己写asyncio循环就得多考虑守护进程、崩溃恢复这些问题。# 每天早上九点执行简报任务 0 9 * * * cd /home/user/clawdbot /usr/bin/python3 main.py --task daily_report logs/daily.log 21日志重定向也是我一开始就加上的。跑智能体没有日志出问题连猜都没法猜。main.py里加了一个--task参数让同一个入口既能执行定时任务也能启动交互式对话服务。这个设计让测试变得很方便——我不用整天跑聊天接口直接运行一次任务就能看到整个管线是否正常。消息推送这块我接的是通用的Webhook机器人。原理很简单往一个URL POST一段JSON消息就会出现在我的手机上。推送代码本身很简单但有一个注意点一定要做频率控制否则一旦某个工具循环出错可能一分钟给你推上百条消息。我后来在调度器里加了一个“每日推送上限”的计数器达到上限就停止推送。4. 踩坑实录新手做智能体最容易翻车的五个地方4.1 上下文管理失控对话超过窗口直接报错第一个大坑是上下文溢出。ClawdBot运行一段时间后我发现在长对话场景下API开始报错提示输入超出最大token数限制。一开始我的处理方式是直接把所有消息一股脑塞给模型想着“模型不是有上下文窗口吗”但实际上每轮使用的token是累加的累积到某个上限就会崩。解决方案是给消息列表加一个“滑动窗口摘要”策略当消息条数超过10轮我会把最早的一部分对话压缩成一段摘要替换掉原始消息。注意摘要不是自己拿大模型生成而是让调度器提取关键词和结论控制摘要本身的长度。这段逻辑大概只有三十行但直接决定了智能体能不能进行持续较长的会话。4.2 模型输出不稳定同一个问题答案天差地别第二个坑是输出不稳定。模型参数里有temperature如果你不调默认值是随机的。ClawdBot早期回答同一道知识性问题两次答案措辞完全不同甚至有一次数据引用错了。后来我把工具调用相关的请求temperature设为0.2纯粹闲聊类的才放开到0.7。这个区分特别重要涉及事实和工具答案应该尽量确定涉及创意、标题、文案可以保留一定随机性。如果没有这个区分你会觉得智能体像一个情绪不稳定的人。另外我还会在工具调用请求里把top_p设为0.8减少低概率分支的采样。这一步很小但效果立竿见影。4.3 定时任务挂掉进程崩溃后不会自愈第三个坑来自异常处理不够充分。有一次我在日志里发现连续两天的早报都没有推送排查后发现是其中一个信息源网站改了HTML结构抓取函数抛了一个超时异常整个定时任务直接中断。因为crontab的配置是“如果前一个进程还在运行后续任务不执行”所以我看到的现象就是“智能体彻底失联”。我做了两层防抖一是给所有工具函数加上超时和重试逻辑二是调度器顶层包了一个try...except任何异常都先写入日志不会被裸奔抛出导致进程退出。再后来我在推送函数里加了一个/status心跳命令ClawdBot每隔六个小时给自己发一条“我还活着”的消息。这个设计虽然土但真的管用。4.4 API调用限流免费额度瞬间耗尽第四个坑是限流和额度。ClawdBot刚上线时我在群聊里开放了测试入口结果半天不到免费额度就消耗殆尽。我看了一下日志发现一个用户连续重发了二十多条消息其中很多都是重复内容每次触发都会完整走一遍大模型调用。补救措施包括同一用户一分钟内最多处理3条消息、相同内容5分钟内不重复处理、每个任务输出长度限制在512个token以内。额度管理看似是资源问题实际是产品问题——你必须在设计上就克制对模型的调用而不是依赖用户自觉。4.5 隐私与安全不要把钥匙写死在代码里最后一个是安全习惯。一开始我在config.py里直接写了大模型的API密钥结果有一次想分享项目截图给朋友差点就把密钥发出去。后来我把所有密钥放到环境变量里用.env文件管理并把.env加入了.gitignore。还有一点是工具权限要最小化。ClawdBot刚学会调用日历工具时我给了它全部日程的读写权限。后来发现它确实能“帮我”加日程但也会在理解错指令时删掉不该删的东西。我不断缩小工具的操作范围——现在它只能读日程、不能删除任何修改类操作都要二次确认。这个教训可能只值一行代码但价值极高。5. 让ClawdBot更进一步升级为MoltBot的经验5.1 从单轮到多智能体ClawdBot稳定运行两周后我开始觉得单智能体的形式有瓶颈。比如我要让它同时完成“收集信息”和“筛选重要信息”两件事在单模型里全部交给提示词控制系统提示词已经膨胀到两千多字效果反而下降。所以我在代号换为MoltBot时做了一次大重构。这次重构最重要的变化是拆成了“情报采集员”和“简报编辑”两个角色。采集员只负责调用抓取工具把原始内容整理成结构化条目编辑再根据预设的关注点筛选和排序。两个角色共用同一个模型API但通过不同的系统提示词隔离职责。说实话这个“多智能体”还没有达到让多个Agent自由对话、互相协作的程度更像是一个流水线。但体验上的提升是明显的每个角色的职责单一提示词更短工具调用准确率反而提高了。如果你也想做多智能体我的建议是从“拆职责”开始而不是一上来就搞复杂的Agent通信协议。5.2 知识库接入让智能体不再“临时抱佛脚”MoltBot的第二个升级点是知识库。早期它回答技术类问题完全靠模型的记忆一旦问到我之前处理过的某个具体项目的细节它就只能瞎编。后来我接了一个轻量级向量数据库把我整理过的笔记、文档切块后做成了索引。用户在群里问了相关问题MoltBot先从知识库检索相关内容再把检索结果和问题一起交给模型组织答案。这个检索增强生成的结构并不复杂但需要特别小心检索质量。有一次它把我一篇关于“数据库备份”的笔记当成“磁盘扩容”的参考回答闹了个大笑话。解决办法是给知识库条目加标签和置信度阈值检索得分低于阈值时宁可告诉用户“没找到”也不要硬答。5.3 人机协作的边界智能体不是用来“代替思考”的最后我想分享一个认知层面的收获。做ClawdBot的过程中我最兴奋的时候是它能自动跑通流程但我最害怕的时候也是它过于“主动”。当它开始基于自己的推断删除日程、把不确定的事情当成确定的事情汇报时我意识到一个问题智能体作为早期系统它的核心价值是帮人节省重复劳动而不是替人做判断。所以我在MoltBot里增加了一个“置信度标注”机制。当模型判断某个操作存在不确定性时它必须在回答里明确写“我不完全确定以下是依据”。这个机制不复杂但非常有效——它强制模型在模糊场景下承认自己的局限。真正的智能从知道自己不知道什么开始。我在实际使用中一个深刻的体会是人生第一个AI智能体成功的关键不在模型多先进而在于你有多了解自己要做的那件事。当你把一个流程拆得足够细你会发现让AI接管其中60%的环节并没有那么难难的是判断剩下40%怎么处理。ClawdBot教会我的不只是怎么调用大模型、写工具函数更是怎么在一个模糊问题面前理清边界。如果你也想做自己的第一个智能体不要一开始就追求无所不能。先让它帮你做一件最烦的重复事再把范围慢慢扩大。这个项目后续我还在继续扩展比如加入语音交互、接入更多外部数据源但所有升级都建立在最初那个朴素的闭环上。你人生中第一个智能体应该也从这样一个极小的闭环开始。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
