古思乱想

原文：Your coding agents made you a manager 作者：Addy Osmani（@addyosmani） 原文配图是 Pangram 对这段文字的检测结果截图：人类写作 90%，AI 10%，AI 辅助 0%。跟正文关系不大，附在此处存档。 编程 Agent 用久了，你已经在做管理 管理 agent 的本事，和管理团队的本事基本是一套。你不需要先有个管理者的头衔才能学。 整天和编程 agent 待在一起，你就在管理。选任务、写指令、派活、追问、评估结果、决定什么上线，一天里反复做这些。把 agent 用得最好的工程师，不一定是 prompt engineering 最强的那批，而是学会了管理的那批，有意识或者无意识地。 这话可能不中听。我欣赏的很多工程师选 IC 路线，就是想贴着活干，他们见过朋友当了管理者之后消失在日历里。我不是劝你变成那种管理者。这里的"管理"有具体所指：通过让别人做成事，来产出好结果。我也没说 agent 能替代管理者或同事。 你对烂管理者的每一条抱怨，都是一份和 agent 打交道的 bug 报告。想想任务交接。要是你经历过一次烂交接，大概收到过含糊的需求、缺失的背景，或者中途被反复改预期。好消息是，正因为你被交接了这么多年，你知道一次好的交接长什么样。 下面这些小节大致按杠杆大小排序，最有效的习惯放前面。 先给它一个能自检的办法 做法： 给 agent 一个验证自己工作的机制，测试套件、构建或者截图都行，让它把结果拿给你看，作为证据。 反例： 把"看起来做完了"当作确认。这样验证全落到你身上，你成了 agent 的测试套件。 问一个有经验的管理者，他怎么在不读所有产出物的情况下确信团队在做好活，他会讲护栏：CI、代码评审、看板、on-call。没建护栏的管理者，最后自己验所有东西，一个季度内就成了瓶颈。agent 一样。Claude Code 的最佳实践文档写得很清楚：agent 在工作看起来做完的时候停下。没有验证机制，“看起来做完"就是它唯一的验证。有了验证机制，agent 就能干活、跑验证、看到失败、自己改。UI 改动可以真的在浏览器里打开页面，迭代到能用也好看。 验证机制是什么都行，只要能给出明确的通过或失败。测试、构建退出码、linter、diff 脚本、截图都算。跑验证的那条命令，是 CLAUDE.md 里最值钱的一行——CLAUDE.md 是 agent 每个 session 开头都要读的指令文件。有了机制，往工作流里接的方式有几种： 要求。 让它做完跑 auth 测试，跑到过为止。 目标。 /goal 会让另一个模型在每一轮之后检查条件，长时间后台任务最用得上。 强制。 Stop hook 可以拦住这一轮的结束，直到 typecheck 通过。 送审。 /code-review 把 diff 交给一个没看过你这段对话的新 subagent 评审，就像作者不批自己的 PR。 评审范围可以控制。让它找问题，它总能找到点东西；让它只找正确性问题、忽略风格，它就照做。好管理者也是这样学会提反馈需求的。Claude Code 工具箱里大部分功能都在收紧这个循环。skills、hooks、subagents、MCP 存在的意义，是补上"做事"和"验证做事"之间的缝，让你的注意力只花在 agent 验证不了的地方。有经验的工程管理者做的就是这件事。 ...

从 Nuxt SSR 到 Worker + R2：一次解耦内容与代码的架构演进 最近，我为 OnlinesTool 完成了一次较大幅度的架构重构。这篇文章最初是迁移收敛时的设计方案，现在它已经全部上线运行，所以我把它更新成了一份实战记录：既保留当时每个阶段的思考与权衡，也补上落地后的真实实现细节、踩过的坑和实测数据。 这个网站最初只是一个纯粹的在线工具站，核心是一批交互型小工具。但为了 SEO 和生态，后来逐步加入了大量**网站目录（Sites）**详情页和 Blog 文章。随着内容规模持续膨胀，一个原本简单的技术选型，慢慢演变成了真正的架构问题。 整个演进过程大致走过了三个阶段： graph LR A["阶段一: Nuxt SSR + Supabase(运行时动态计算)"] B["阶段二: Nuxt 全静态生成 SSG(构建时全量生成)"] C["阶段三: 双引擎分离架构(Nuxt Assets + Worker + R2)"] A -->|"解决 SSR 限流, 却引入 20 分钟 Build"| B B -->|"代码发布与内容发布彻底解耦"| C有意思的是，第二个方案其实已经解决了第一个方案的大部分问题，但最终我并没有停在 SSG 这一步。因为当运行时的问题解决以后，构建时的问题又冒了出来。本文就完整记录这个过程：每一处的权衡、数据链路、最终的实现细节，以及上线之后真实发生的那些故障与修复——方案收敛只是下半场的开始。 一、阶段一：Nuxt SSR + Supabase 的困境 1.1 初始架构 OnlinesTool 部署在 Cloudflare 上。最初的架构是常见的全栈 SSR：页面由 Nuxt 在服务端渲染，Site 和 Blog 的结构化数据存放在 Supabase（PostgreSQL + PostgREST API）。 sequenceDiagram autonumber actor User as 用户 / 爬虫 participant CF as Cloudflare Edge participant SSR as Nuxt SSR (Worker) participant DB as Supabase User->>CF: 发起页面请求 e.g. /zh/sites/atlassianrovo CF->>SSR: 转发到 Nuxt Worker SSR->>DB: 按 slug 查询 Site/Blog 数据 DB-->>SSR: 返回原始数据 SSR->>SSR: Vue SSR 渲染完整 HTML SSR-->>CF: 返回 HTML CF-->>User: 响应页面对开发来说，这套架构很舒服：数据库里新增一条记录，前端马上就能出页面，完全不用重新构建网站。Blog 也是一样的逻辑，从 CMS 的角度看这套架构没有明显问题。真正的麻烦出现在 Cloudflare Worker 的运行时上。 ...

我之前使用 Cloudflare Pages 部署 Hugo 博客时，最开始考虑的是直接使用 Cloudflare Pages 的 Git 集成：把 GitHub 仓库连接到 Cloudflare，之后每次推送代码就自动构建。 这种方式很简单，但构建过程完全由 Cloudflare 控制。如果希望自己控制 Hugo 版本、主题子模块初始化、构建命令和部署时机，也可以把整个过程放到 GitHub Actions 中完成。 本文记录我现在采用的方案： push 到 master │ ▼ GitHub Actions │ ├── 拉取源码和 PaperMod 子模块 ├── 安装 Hugo Extended ├── 构建 public/ └── 使用 Wrangler 部署到 Cloudflare Pages 这套方案适合什么情况？ 如果只是想实现“推送代码后自动发布”，Cloudflare Pages 自带的 Git 集成已经够用。 GitHub Actions 更适合下面这些情况： 希望固定 Hugo 版本，保证本地和 CI 构建结果一致； 需要在部署前加入测试、格式检查或链接检查； 希望自己控制哪些分支可以部署； 已经把 CI/CD 统一放在 GitHub Actions 中； 希望构建过程和 Cloudflare 解耦。 需要注意的是，不要同时开启 Cloudflare Pages 的 Git 自动部署和 GitHub Actions 部署。否则一次 push 可能触发两次构建和两次发布。 ...

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 关心这些能力如何跨渠道、跨任务、跨模型长期运行。 这三者不是名字的区别，是工程边界的区别。 ...