AI

04. 你的 Agent 越改越乱？先把这 8 个对象分开 系列来源：本文属于 Agent 开发系列，内容来自 gusibi/molibot 的真实开发记录与项目文档整理。这是系列第四篇，前三篇分别讲了 Agent 的四层分类、runtime 整体架构和最小 run 闭环——没看过不影响理解本篇。 你有没有过这种经历—— Agent demo 跑通以后，你开始往上加功能。文件上传、图片生成、记忆、停止命令、trace 页面。 然后系统开始变乱。 加个「停止」功能，不知道该停哪一次执行。工具失败了，模型却看不到错误。清理临时文件，把用户要的报告一起删了。排查线上问题，只能翻聊天记录猜。 你以为是代码写得不好。其实不是。 是对象混在了一起。 Session 和 run 混了，停止命令不知道该停哪次执行。 Tool result 和 assistant answer 混了，模型看不到真实工具结果。 UI notice 和 message 混了，临时控制污染后续上下文。 Artifact 和 attachment 混了，用户上传的文件和 Agent 生成的产物一起被清理。 Trace fact 和业务消息混了，排障记录又被回灌给模型。 这些问题，demo 阶段一个都看不出来。因为只有一条消息、一个工具、一次执行，混了也能跑。 但系统只要长期运行，边界就会反过来找你。 这篇不画漂亮的类图，只回答一个问题：Agent runtime 里，哪些东西必须分开？ 一个对象混乱的事故 先看一个真实场景。 用户发来： 帮我分析这个日志文件，如果里面有异常，生成一份报告。 系统做了四件事：读日志、调模型分析、生成 HTML 报告、把链接发给用户。 这时用户又补了一句： 先停一下，我发现上传错文件了。 如果对象边界不清，这里会同时出现五个问题。 第一，系统不知道「停一下」要停哪次执行。它只有 session，没有 run。session 里有很多消息，但没有一个明确的 active run。 ...

03. 没有 Run 对象，你的 Agent 只是个高级 Chatbot 套壳 系列来源：本文属于 Agent 开发系列，内容来自 gusibi/molibot 的真实开发记录与项目文档整理。这是系列第三篇，前两篇分别讲了 Agent 的四层分类和 runtime 的整体架构——没看过不影响理解本篇。 你有没有过这种经历—— 线上 Agent 出问题了，你翻日志翻了半小时，还没搞清楚它当时到底在执行哪个任务。用户问"刚才那个请求还在跑吗"，你只能回答"大概吧"。服务一重启，内存里那些 running 状态全丢了，外面还以为任务卡住了。 如果你有过，那这篇就是写给你的。 上一篇我们区分了 Chatbot、Tool-using Chatbot、Agent Service 和 Agent System。结论很简单：差别不在模型，而在 runtime。 但 runtime 这个词还是太大了。真正落到工程里，第一个问题应该更小： 一条用户消息进来以后，系统到底怎么把这一轮跑完？ 先别急着做多 Agent。也别急着接 Telegram、飞书、微信。更不要一开始就设计一堆工具市场、插件系统、长期记忆。 如果一轮 run 都跑不清楚，后面所有功能都会挂在一团不稳定的东西上。 没有 Run 对象的 Agent 系统，本质上还是个 Chatbot 套壳。 这一篇只讲一件事：一个最小 Agent 服务，如何把一轮 run 跑清楚。 为什么先讲 run？ 很多 Agent demo 没有 run 的概念。 用户发来一句话，程序把历史消息拼一下，调用模型。模型要工具，就执行工具。最后把回答发回去。 看起来也能跑。 ...

等 AI 写代码的两分钟，我做了一个练英语的 macOS 小工具 我经常遇到一个很尴尬的空档：AI 正在生成代码，测试还没跑完，手头有两三分钟，但又不值得开始一项新任务。 以前我通常会点开一部短剧，或者顺手刷几个短视频。本来只想打发等待的两分钟，结果短剧一集接一集，视频一条接一条，很快就把这段时间浪费掉了。 更麻烦的是，看短剧和刷视频会把注意力完全拉走。同事的消息错过了，AI 的代码早就生成完了，测试也已经跑完，我却常常过了好一会儿才想起来：我刚才明明只是想等两分钟。 所以我做了一个 macOS App，叫 BestLearn。 它解决的不是“没有时间学英语”，而是“两分钟的空档，不值得为学习付出一整套启动成本”。 它平时藏在桌面边缘。按一个快捷键，屏幕下方会浮出一条很窄的英语练习栏。编辑器、AI 的生成进度和测试日志都还在上面，我随时能看到任务跑到哪了。 练几句，按 Esc 把它收起来，继续刚才的工作。不需要切换窗口，也不会因为刷视频忘了时间。 实际怎么练 BestLearn 会把同一组句子拆成三个环节： 抄写：看着原句输入，先熟悉表达和拼写。 默写：只听音频，不提前显示答案。 填空：保留上下文，只输入缺失的内容。 输入正确的部分会变绿，错误字符会标红。答错后，App 会显示正确答案，然后继续下一句。 我没有设计成“答错必须重打三遍”。等代码时的练习本来就很短，我不想让它卡在同一句上。 三个环节也不用每次全部练完。在办公室不方便播放声音，我就只做抄写或填空。戴上耳机后，再单独练默写。 我平时基本不用鼠标，所以几个常用操作都配了快捷键。 操作 默认按键 呼出或隐藏学习条 Shift + Alt + B 快速隐藏并停止音频 Shift + Alt + H 在面板内隐藏 Esc 打开课程选择 Command + K 跳过 / 重播 / 结束 ⌘1 / ⌘2 / ⌘3 课程选择、环节开始和结算页会直接标出数字选项。答题时改用 ⌘+数字，避免把句子里的数字当成命令。 ...

02. 从 Chatbot 到 Agent Service：差别不在模型，而在运行时 系列来源：本文属于 Agent 开发系列，内容来自 gusibi/molibot 的真实开发记录与项目文档整理。 上一篇我们先画了一张地图：一个 Agent 系统不只是模型和工具，还会自然长出入口层、runtime、工具层、状态层、权限层、观测层和后台。 但如果只看概念，这些层还是有点抽象。 所以这一篇先解决一个更具体的问题：Chatbot、Tool-using Chatbot、Agent Service、Agent System 到底有什么区别？ 这个问题很重要。 因为很多团队第一次做 Agent，最容易卡在这里：系统明明已经能调用工具了，却还是很难稳定地交给用户用。用户一刷新，状态没了；工具失败后，模型不知道发生了什么；任务执行一半，用户想停止，后台还在跑；生成出来的文件，本地能看到，发到平台却失败。 这时如果继续堆 prompt，通常没用。 问题不在模型，而在运行时。 先用一个真实任务来看差别 假设用户发来这样一个需求： 帮我生成一张赛博朋克风格的猫咪海报。 如果效果可以，再用这张图生成 5 秒短视频。 最后把图片和视频都发给我。 这个任务很适合用来区分不同系统。 它看起来只是“调用两个工具”：先生成图片，再生成视频。 但真实执行时，马上会出现很多细节： 图片生成是同步返回，还是异步任务？ 图片结果是本地路径，还是公网 URL？ 视频服务能不能访问本地文件？ 生成成功但平台上传失败，算不算失败？ 用户中途说“停一下”，已经提交的视频任务怎么办？ 后台能不能查到这个任务用了哪个模型、哪个工具、哪个 provider？ 用户第二天追问“昨天那张图再换个风格”，系统还能找到原始结果吗？ 如果这些问题没有回答，你做出来的可能只是一个能演示的工具链，不是一个 Agent 服务。 下面我们按四个层级来看。 第一层：Chatbot 只负责回答 最普通的 Chatbot 会怎么处理这个任务？ 它会回答一段文字。 可能是这样： 当然可以。你可以先使用图片生成模型生成一张赛博朋克风格猫咪海报， 再把生成结果作为参考图传给视频生成模型。 这个回答不一定错。 但它没有做事。 ...

01. 课程导读：Agent 服务和 Agent 系统的全景图 你是不是也遇到过： 看了一堆教程，写了一个能调用工具的 Agent demo，自己跑起来样样都好 真接给用户用，刷新就丢状态，工具错了模型不知道，用户喊停了后台命令还在跑 想接第二个渠道，发现 80% 代码要重写 这些问题，从来都不是模型聪不聪明的问题。 它们属于另一件事：你有没有把 Agent 做成一个服务。 一句话记住：Demo 拼模型能力，服务拼工程边界。 这组文章要讲的，就是这件事。 不是怎么调一个大模型 API。不是怎么写一句神奇 prompt。也不是把几个工具函数绑到模型后面，然后说"这就是 Agent"。 我想从一个真实系统的角度，拆开看：一个 Agent 服务从最小闭环走到完整系统，中间到底要补哪些层。你读完这一篇，先不需要记住所有细节，但应该有一张地图。后面每篇文章，都能在这张地图上找到位置。 为什么"能聊天"不等于 Agent 服务？ 普通聊天机器人只需要完成一件事：用户问一句，模型答一句。 它也可以有多轮上下文，但本质上还是"生成回复"。只要回答看起来合理，这一轮就结束了。 Agent 不一样。 Agent 的关键不是"会说"，而是"会做"。它可能要读文件、查网页、执行命令、调用图片生成服务、创建定时任务、写入记忆、等待用户审批、把结果发回不同平台。 只要开始"做事"，系统就不再只是模型调用了。 因为做事会带来后果。 比如用户让 Agent 修改一个配置文件。一个聊天机器人可以告诉你"应该这么改"。一个工具增强聊天机器人可能会真的写文件。但一个 Agent 服务还要继续回答： 写之前有没有确认路径在允许范围内？ 写坏了有没有记录旧内容？ 工具失败后，模型能不能看到失败原因？ 用户中途停止时，文件写入有没有被打断？ 最终结果有没有保存到这次 run 的记录里？ 过几天排查问题时，能不能知道当时发生了什么？ 这些问题如果没有答案，系统可能仍然能 demo，但很难交给真实用户长期使用。 所以这组文章的第一条判断是： Chatbot 关心回答。 Agent Service 关心一次行动如何被执行、记录、恢复和约束。 Agent System 关心这些能力如何跨渠道、跨任务、跨模型长期运行。 这三者不是名字上的区别，而是工程边界的区别。 ...

一个工程师，一个月合了 259 个 PR，而且他说这些代码基本不是自己手写的。他做的事情，是写一套 Loop，让 Agent 自己去发现问题、改代码、跑检查、再进入下一轮。另一边，也有人把 Loop 放着跑了 11 天，最后烧掉 4.7 万美元。 同样一件事，一个人把它变成产出，一个人把它变成账单。差别不在模型，在于他们怎么设计那个循环。 Loop Engineering 听起来像新一轮 AI 黑话，但它背后有个真实的变化： 人不再站在循环里，一轮一轮提示 Agent。人开始站到循环外，设计那个提示 Agent 的系统。 这句话才是重点。Loop 本身不神秘，最朴素的形态就是一个 while 循环： 观察当前状态 决定下一步 执行动作 检查结果 如果没完成，就继续 这东西早就存在，ReAct、AutoGPT、LangGraph、human-in-the-loop 本质上都离不开它。2026 年大家重新讨论它，不是因为 while 变高级了，而是因为 Agent 能做的事情多了。以前你让它补一段代码，现在你可以让它看 issue、开 worktree、修测试、提 PR、等 CI、处理 review comment，甚至第二天接着跑。 于是问题就变了。不再是"怎么写一句好 prompt"，而是：怎么设计一套能持续转动、能自我检查、能及时停下来的工作系统。 这就是 Loop Engineering。 为什么大家突然开始讲 Loop？ 过去两年，我们用 Agent 的方式大多是这样的： 你写 prompt Agent 干一轮 你看结果 你指出问题 Agent 再干一轮 你继续看 表面上是 Agent 在工作，其实你才是那个 Loop。下一步该干什么、结果对不对、要不要继续、上下文乱了要不要重整，全靠你判断。所以你会累——不是因为模型不够强，而是整个反馈循环还挂在你身上。 ...

系列来源：本文属于 Agent 开发系列，内容来自 gusibi/molibot 的真实开发记录与项目文档整理。 原文：02-内容创作/02-图文长文/agent-dev-series/01-course-map.md 重写说明：本文是 01-course-map.md 的重写版，保留原有核心观点，调整了结构和表达，并更换了标题。 为什么很多 Agent Demo 能跑却不能上线？一张图讲清 Agent 服务全景 你可能见过这样的 Agent demo：能聊天，能调用工具，能读文件，甚至还能生成图片。看着很厉害。 但真把它接给用户，问题立刻就来。 用户刷新页面，刚才那个任务还在不在？工具执行失败了，模型还知不知道失败原因？用户发了一句"停一下"，后台命令真的停了吗？如果同一个 Bot 同时接 Telegram、飞书和 Web，排队、审批、记忆和上下文到底写在哪里？ 这些都不是"模型聪不聪明"的问题。 它们是另一件事：你有没有把 Agent 做成一个服务。 这组文章要讲的就是这件事。不是怎么调大模型 API，不是怎么写一句神奇的 prompt，也不是把几个工具函数绑到模型后面就叫 Agent。我想从一个真实系统的角度拆开看：一个 Agent 服务从最小闭环走到完整系统，中间到底要补哪些层。 这一篇你不用记住所有细节，但读完应该手里有一张地图。后面每篇文章，都能在这张地图上找到自己的位置。 为什么"能聊天"不等于 Agent 服务？ 普通聊天机器人只做一件事：用户问一句，模型答一句。 它也能有多轮上下文，但本质还是"生成回复"。只要回答看起来合理，这一轮就结束了。 Agent 不一样。它的关键不是"会说"，而是"会做"。它可能要读文件、查网页、执行命令、生成图片、创建定时任务、写入记忆、等待审批、把结果发回不同平台。 只要开始做事，系统就不再只是一次模型调用了。 因为做事会带来后果。 比如用户让 Agent 改一个配置文件。聊天机器人会告诉你"应该这么改"；工具增强的聊天机器人可能真的去写文件；但一个 Agent 服务还得继续回答这些问题： 写之前确认过路径在允许范围内吗？ 写坏了，旧内容有没有留底？ 工具失败了，模型能看到失败原因吗？ 用户中途喊停，文件写入会不会被打断？ 最终结果有没有存进这次 run 的记录？ 过几天排查，能不能还原当时发生了什么？ 这些问题没有答案，系统也许还能 demo，但很难交给真实用户长期用。 所以这组文章的第一条判断是： Chatbot 关心回答。 Agent Service 关心一次行动如何被执行、记录、恢复和约束。 Agent System 关心这些能力如何跨渠道、跨任务、跨模型长期运行。 这三者不是名字的区别，是工程边界的区别。 ...

原文： 01-选题与灵感/01-待深化选题/mattpocock skills 推荐.md 01-选题与灵感/01-待深化选题/X 上的 Kieran Zhang介绍一下我最喜欢的 agentic coding skills 套件作者 mattpocockuk 刚刚正式发布 v100 版本了相比旧版本有了不少的改动今天从全局视.md 重写说明：基于两篇原文合并重写，保留推荐口吻，调整成一条更清楚的「idea → ship」主线。 Matt Pocock 的 skills v1，最值得看的不是清单，而是一套工程工作流 最近我在看 Matt Pocock 的 skills，发现它有一种很明显的活人气息。 很多 AI workflow 看起来像框架设计文档，概念很满，但你很难判断作者是不是真的每天在用。 Matt 这套不一样。 它的 README 里写得很直接：这些 skills 来自他的 .claude 目录，是他自己每天做真实工程时用的东西。不是为了包装一个完美框架，而是把一些工程师真的会踩的坑，拆成一组很小、很具体、可以组合的工作流。 说得再直白一点： 这套 skills 的重点不是“让 AI 更会写代码”，而是“让人和 Agent 更不容易一起跑偏”。 这次 v1 发布之后，结构比之前清楚很多。官方 README 现在把 skills 分成两类： User-invoked skills：你主动输入命令触发，比如 /grill-me、/to-prd。 Model-invoked skills：Agent 在合适的时候自动使用，比如 tdd、domain-modeling、codebase-design。 这个划分很关键。 ...

上一篇我写过，为什么我最后选了 Anthropic 的 sandbox-runtime。 当时想得很简单。 我不想为了一个个人 AI 助手，一上来就搞 Docker、远程 VM、完整容器平台。 那套当然更强，但成本也更高。 我真正想要的是一个轻量边界：Agent 还能在本机干活，但不能随便摸到宿主机所有东西。 所以我选了 Anthropic 的 runtime。 但真正接进去以后，我很快发现一件事： 沙箱不是一个开关。它更像 Agent runtime 里的一条执行边界。 尤其是 Molibot 这种形态。 它不只是一个网页里的聊天框。 它同时服务 Web、Telegram、飞书、微信、QQ。 里面还有 subagent、工具调用、审批恢复、长任务、会话持久化。 这时候真正难的，已经不是“怎么把命令放进沙箱跑”。 真正难的是： 当沙箱挡住 Agent 时，runtime 接下来应该怎么办？ 这篇就记录一下，我把 sandbox-runtime 接进 Molibot 时踩过的几个坑。 我一开始只想给 bash 套一层沙箱 Molibot 是我自己做的本地优先 AI 助手。 它的核心不是某个聊天入口，而是一套共享 runtime： Web Chat 可以对话、传文件、看运行状态； Telegram、飞书、微信、QQ 都接到同一套 Agent； Agent 可以调用 bash、MCP、图片生成、搜索、subagent； 会话、设置、审批记录、任务记录都落在本地 JSON/SQLite。 所以我最开始的目标很克制： 先只管 Agent 和内置 subagent 的 bash； Browser、MCP、渠道收发先不进沙箱； 普通 shell 默认在 sandbox 里跑； 文件系统、网络、环境变量从设置页控制； 真要用宿主机能力，再走人工审批。 听起来是一个挺正常的工程任务。 ...

上周我尝试让 Agent 帮我重构一个项目（其实就是想偷个懒）。它跑了大概 20 分钟，中间噼里啪啦执行了四十多条 shell 命令——装依赖、改配置、跑测试，甚至还动了 .git 目录。 跑完我回头看了一眼日志，冷汗直接下来了：中间有好几步，如果它命令写偏了一个字符（比如把 rm -rf ./tmp/ 写成了 rm -rf /），我的本地环境大机率当场报废。 这还不是最可怕的。最可怕的是，当 Agent 每一步都弹窗问我“允许执行吗”的时候，我发现自己根本没仔细看——点了二十次“允许”之后，那个确认按钮已经变成了我的肌肉记忆。 这就是今天要聊的问题：Agent 越来越能干活了，但谁来管住它的手？ 弹窗确认，其实是个心理安慰 很多人觉得，让 Agent 每执行一步都弹窗确认就够了。看起来很“民主”，实际上有两个致命问题。 第一，中断疲劳。一个正经的重构任务，可能涉及十几次文件读写、几十条 shell 调用。如果每一步都确认，Agent 的自动化价值就直接归零了。你雇了个助手，结果它每个动作都要你签字，那跟你自己干有什么区别？（这还不如我自己手写呢。） 第二，弹窗防不住真正的风险。你真的能在 1 秒钟内审完一长串 bash 命令吗？被混淆过的脚本、链式调用、隐蔽的数据外带——肉眼根本看不出来。本质上，弹窗确认是在把安全责任甩给用户，而不是在系统层面建立边界。 🔑 核心观点：车速越快，护栏越重要。你不能靠“每次变道都问一下副驾”来解决安全问题。 真正可持续的方案是：把 Agent 放进一个边界明确的区域，边界内自动跑，越界直接拦——不打扰，不甩锅，靠机制而不是靠注意力。 这就是 Agent 沙箱要干的事。 三条路线，各有各的算盘 目前行业里做 Agent 沙箱，大致有三条路线。它们不是谁淘汰谁，而是各适合不同的场景（或者说坑位）。 1. 容器型：Docker 一把梭 把代码执行环境塞进独立容器，通过 API 和 Agent 主流程解耦。 优点很明显：环境一致性好、多租户调度方便。很多云端 Agent 平台（比如那些做代码执行服务的）都走这条路。 但如果你要做的是“让 Agent 在我的本地项目里帮我干活”，Docker 就有点笨了。Volume 映射、路径同步、宿主文件和容器视图的一致性……一堆问题等着你。它更适合“把任务送进隔离盒子执行”，不太适合“在我当前工作区无缝协作”。 ...