My Home

Personal Agent：把不确定性纳入架构的自进化方法

Thu, 05 Nov 2026 00:00:00 +0800

Personal Agent：把不确定性纳入架构的自进化方法

开头：Agent 的问题不是“像不像函数”

传统软件习惯把能力封装成函数：输入明确、逻辑可重复、输出可校验。Personal Agent 不同，它需要理解自然语言、判断上下文、选择工具并规划多步行动，结果天然带有不确定性。

这并不意味着 Agent 不能工程化。相反，关键是把 Agent 当作一种可约束、可观察、可复用的执行单元，再用确定性组件把它放进可靠的工作流。

一、Agent 函数化：约束接口，而不是假装确定

Agent 可以被“函数化使用”，但不应被误认为传统函数。工程上要先定义输入边界、输出格式、可调用工具和失败处理，再给它一个清晰的任务单元。Agent 负责理解和探索，代码负责校验、状态转换、权限和落盘。

这是一种混合架构：不确定性用于处理开放问题，确定性用于守住硬边界。对于无法接受模糊结果的步骤，必须增加结构化输出、格式验证和回读确认。

二、确定性门禁与环境改造

单靠提示词很难消除幻觉。更有效的做法是改造 Agent 所处的环境：减少不必要的选择，限制工具权限，提供明确的契约，在关键节点放置确定性门禁，并让结果可以被追踪和重放。

门禁不必把所有工作变成规则。它只需要守住高风险边界，例如身份、权限、状态版本、外部发布和不可逆操作。这样既保留模型的泛化能力，又降低错误穿透系统的概率。

三、自进化不是“写一段总结”

自进化必须有证据链。一次可靠的改进至少包括：记录失败现象；保留当时的输入、上下文和动作；判断根因属于模型、提示、工具、流程还是环境；提出一项具体修改；用历史案例或回归测试验证；确认没有引入新的副作用。

如果只有“下次注意”，而没有可比较的指标和可重放案例，系统并没有真正学会。可以观察任务成功率、人工返工率、错误类型分布、重试次数或流程耗时，但指标必须服务于实际目标，不能为了数字而优化数字。

四、多 Agent、弱 Session 与 Super Agent

当任务复杂度超出单个 Agent 的注意力范围，多 Agent 可以按职责拆分：研究、规划、执行和审核分别拥有更窄的上下文与权限。弱 Session 则意味着不依赖一段无限延续的对话，而是把关键状态落到外部可读、可恢复的记录中。

Super Agent 更适合被理解为协调层：负责拆解任务、选择执行者、汇总结果、发现异常并决定是否升级，而不是亲自完成一切。层级越多，协调成本越高，因此只有在职责、权限或验收标准真正不同的时候才值得拆分。

五、停止搭建，开始沉淀作品

素材中的另一个提醒是：系统可以不断变复杂，但复杂本身不是产出。已有的配音、写稿、视频和分享能力，应该优先沉淀为具体作品并持续发布；新的基础设施只有在能缩短反馈周期、降低重复劳动或提高质量时才值得加入。

这也是自进化的现实检验：不是系统声称自己更强，而是下一次真实任务是否更快、更稳、更少返工。外部发布仍应保留人工审阅，未经确认不能自动把草稿变成公开内容。

结语：把不确定性放在可控位置

Personal Agent 的工程路线不是消灭不确定性，而是安排它出现的位置：让 Agent 负责理解、规划和探索，让确定性代码负责校验和状态，让工作流负责边界和交账，让指标与回归测试推动改进，让人在高风险出口保留最终确认权。

这条路线把“自主”从一句口号变成可验证的闭环：观察、约束、执行、测量、回归，再迭代。本文基于指定 daily-thoughts 素材，强调发布前应保留人工审阅。

要点回顾

覆盖 Agent 函数化、确定性门禁、环境改造、自进化指标化、多 Agent、弱 Session 与 Super Agent。
明确区分素材中的观点与工程化推导，没有补写未经来源支持的经历。
保留人工审阅，现已通过 GitHub 发布。

Personal Agent、自进化与确定性—不确定性架构

Wed, 04 Nov 2026 00:00:00 +0800

Personal Agent、自进化与确定性—不确定性架构

引言：问题不是“模型够不够聪明”

Personal Agent 的难点，不只是让模型生成更好的答案，而是让一个具有不确定性的执行单元，在真实环境中持续完成任务、接受校验，并在出错后改进。更有用的工程问题是：哪些环节交给 Agent，哪些环节必须由确定性代码、规则和人工确认负责？

本文基于 2026-11-04 的随想素材，区分“素材中直接表达的观察”和“据此作出的工程化推论”，不把推论写成已验证事实。

一、Agent 不是传统函数，而是高不确定性执行单元

传统函数通常有明确输入、固定逻辑和可预期输出；Agent 则会理解意图、选择工具、规划步骤，并根据环境反馈调整行为。同一目标可能得到不同路径，调用工具也可能失败。因此，不能把 Agent 当作一个“更大的函数”直接替换进旧程序。

更合理的组合方式是：让 Agent 处理需要理解、判断和规划的部分，让确定性程序处理结构化、可验证、不可出错的部分。例如，Agent 可以提出计划或抽取信息；代码负责格式校验、权限检查、状态机推进和结果落盘。两者交替组合，比单纯追求一个全能 Agent 更容易控制风险。

二、环境设计比提示词堆叠更重要

当 Agent 反复犯同一类错误时，继续增加提示词未必有效。可以改造它所处的环境：缩小可选动作范围，提供明确的工具契约，在关键节点加入校验和回读，把成功标准变成可观察的状态，并保留失败记录。

这意味着“让 Agent 变好”不一定等于训练一个更强的模型，也可以是改变任务分解、工具接口、反馈机制和权限边界。环境把隐含要求变成显式约束，能降低幻觉和误操作的代价。

三、多 Agent 与 Super Agent：分工不是越多越好

多 Agent 的价值在于角色分工：不同 Agent 可以负责研究、写作、审核或执行，各自拥有更清晰的职责。但层级越多，协调成本、状态同步和责任追踪也越复杂。Super Agent 并不意味着一个无所不能的角色，更像是负责规划、分派、汇总和监督的协调层。

设计时应先问：这个角色是否有独立的上下文、权限或验收标准？如果没有，拆分可能只是增加通信开销。无论采用单 Agent 还是多 Agent，都需要明确谁启动任务、谁检查结果、谁有权推进状态，以及失败后如何回退。

四、自进化必须落到指标与回归测试

“自进化”不能只理解为 Agent 自己总结几句话。可复用的改进至少应包含：记录失败现象和上下文；定位是提示、工具、流程还是环境问题；提出改动；在相同或相近案例上回归验证；确认改动没有引入新的错误；最后再把经验沉淀为规则、技能或测试。

如果没有指标和回归测试，所谓进化可能只是换一种说法重复失败。可观测的状态、可比较的结果和可重放的案例，是让不确定系统逐渐可靠的基础。

五、从工作流到 Personal Agent：先做闭环，再谈自主

工作流擅长确定性的节点推进：任务进入、条件判断、权限校验和状态转换都可以被记录。Personal Agent 擅长在节点内部处理开放性工作。两者结合时，工作流负责边界与交账，Agent 负责节点内的探索和执行。

因此，“自主”不应等同于不受监督。更现实的定义是：Agent 能自主规划和启动一段工作，但必须在可观测、可暂停、可回滚的环境中运行，并在需要时把问题交还给人。人工审阅不是系统失败，而是高风险内容发布前必要的控制点。

结语：把不确定性放在可控的位置

Agent 工程的关键不是消灭不确定性，而是把不确定性放在适合它的位置：让它负责理解和探索，用确定性代码约束边界，用工作流记录状态，用指标和回归测试验证改进，用人工审阅守住高风险出口。

这条路线不承诺一次搭出完美的 Personal Agent。它提供的是一个可以逐步验证的工程闭环：观察问题，改造环境，组合 Agent 与确定性组件，测量结果，再根据证据迭代。本文强调在高风险出口保留人工审阅，发布前应完成必要的验证与授权。

要点回顾

覆盖 Agent 与传统函数、确定性与不确定性
覆盖环境设计、多 Agent 层级与 Super Agent
覆盖幻觉治理、指标化、回归测试与自进化
区分素材观察与工程化推论，未添加未经来源支持的个人经历
保留人工审阅，现已通过 GitHub 发布

智能的本质是压缩：用状态机和控制论重构 Agent 系统

Sat, 10 Oct 2026 07:36:00 +0800

最近我越来越觉得，Agent 系统的问题不能只归结为模型能力。有时执行器主动性不足，任务很快停下来；有时安全管家又过度保护，让部署推进变慢。真正需要重构的，是模型、治理、工作流和运行环境之间的关系。

治理不能变成过度保护

安全治理当然重要，但保护规则也需要被反向检查。如果每个动作都被过多的确认和限制卡住，系统虽然看起来安全，却很难把事情做完。

更合理的方式是一边治理、一边开发：持续测试功能，也定期扫描哪些保护已经变成了不必要的摩擦，再在审计后清理它们。治理的目标不是让 Agent 什么都不能做，而是让它在边界内持续执行。

多条任务线之后，瓶颈回到了人

通过消息工具派发任务、推进工作流，是一种很有价值的模式。人可以在手机端提出目标，由 Agent 派发任务并跟踪进度，而不是亲自执行每个动作。

但当任务线路变多，人的脑力会成为新的瓶颈。问题变成：我如何接收多条线的状态信息，又如何快速给出反馈？如果系统把所有细节原样推给人，信息越多，越难推进。

因此，状态信息必须被转换成人类容易理解的分类：当前处于哪一阶段、接下来可以做什么、依赖是什么、是否阻塞。只有这样，多条工作流才不会变成多条互相争夺注意力的消息流。

状态机让复杂流程可理解

我认为，最适合表达 Agent 任务进度的模式可能就是状态机。状态机描述当前处于哪个状态，以及在这个状态下应该执行什么行为、什么条件会触发下一步流转。

从本质上说，Agent 的执行流程和传统程序并没有完全不同。传统程序沿着固定的 if/else 顺序流转；Agent 则在各个节点中加入自己的判断和一定的随机性。顺序流转仍然存在，只是节点内部变得更灵活，因而能够处理更复杂的工作。

状态机的价值，是把这种灵活性放在清晰的边界里。系统知道任务走到哪里，也知道当前状态允许哪些行为。Agent 可以在节点内部寻找解法，但不能随意改变整体流程。

智能的一部分，是把步骤压缩

Agent 执行任务时，会发现一些可以复用的规律。原本需要逐步展开的一串动作，经过理解和沉淀后，可以被压缩成一个更高层次的动作。

我越来越倾向于把这种压缩看成智能的重要组成部分：把多个步骤压缩成一个步骤，把反复试错得到的经验反馈回环境，再把经验变成规则、模块或 Skill。压缩得越多，下一次执行时就越不需要重新消耗上下文，也就能把能力用于更复杂的问题。

因此，环境中那些 Agent 处理不好的内容，不应该只被当成一次失败。它们应当被记录下来，反馈回系统，推动架构、模块和工作流继续改进。

用控制论形成反馈闭环

控制论和系统论提供了另一个重要视角：系统不是执行一次就结束，而是通过反馈不断修正自己。Agent 做出动作，环境返回结果；结果暴露出的偏差，再进入下一轮治理和设计。

代码架构中的模块化、工作流中的任务拆解、状态机中的流转条件，以及控制论中的反馈回路，实际上共同指向一个目标：让系统能够观察自己、修正自己，并逐步形成更好的正反馈。

这也解释了为什么应该把运行环境搭建好。环境足够清楚、边界足够稳定、反馈足够及时，即使 Agent 的智力变强，也只能在这个环境里寻找最优解法，而不能越过环境随意行动。

让耐心沉淀为系统

现在做了很多工作，却还没有形成足够显性的成果，这确实会让人揪心。支撑我继续推进的，是相信耐心本身可以产生复利，但耐心不能只是等待。

每一次执行、失败和修正，都应该沉淀为系统的一部分：更清楚的状态、更稳定的环境、更好的反馈和更少的重复劳动。最终要构建的，不是一个需要人不断盯守的 Agent，而是一个能够在约束中寻找解法、在反馈中持续迭代的系统。

状态机、控制论和环境治理：重构 Agent 系统

Sat, 10 Oct 2026 07:36:00 +0800

最近越来越清楚地感觉到，Agent 系统真正的瓶颈不只是模型能力，也不只是某一个执行器是否足够主动，而是整个运行环境有没有被设计成一个可理解、可反馈、可持续迭代的系统。

先承认执行质量并不稳定

有些管家型 Agent 在执行任务时会很快停下来，主动性不足，部署推进也因此变慢。遇到这类情况，不能把全部工作都寄托在单一的管家上；需要让更适合长程执行的 LLM 参与具体工作，同时保留原有的安全治理。

但安全治理本身也可能走向另一个极端：过度保护。一个系统如果对每个动作都设置过多阻碍，Agent 虽然更安全，却很难把事情做完。因此，治理不能只是不断增加限制，也应该定期检查哪些保护已经变成了不必要的摩擦，并在测试和审计后清理它们。

比较现实的方式，是一边治理、一边开发。功能继续推进，测试和审计持续补上；当某个保护规则阻碍了正常执行，就回到系统层面判断它是否合理，而不是临时绕过所有边界。

多条工作流之后，瓶颈回到了人

通过飞书 CLI 派发消息、推进工作流，是一种很有价值的模式。手机端不必亲自完成每个动作，只需要和一个入口聊天，由它派发任务、跟踪状态，再把结果反馈回来。

但是当任务线路变多，人的脑力仍然会成为瓶颈。问题不再只是 Agent 能不能执行，而是人能不能快速理解各条线现在处于什么状态，并给出下一步反馈。如果系统把大量细节原样推给人，信息越多，反而越难推进。

因此，任务状态必须被翻译成人类容易理解的分类：当前在哪个阶段、下一步能做什么、依赖是什么、是否阻塞。只有状态信息足够清楚，人才能在多条工作流之间做出有效决策。

用状态机表达任务进度

我越来越倾向于把 Agent 工作流理解成状态机。状态机回答的是：现在处于哪一步？在这个状态下允许执行什么行为？什么条件会触发下一次流转？

从这个角度看，Agent 的执行流程和传统程序并没有本质断裂。过去的程序是固定的 if/else 和顺序流转；Agent 则在这些节点中加入了判断和一定的随机性。它仍然需要沿着状态前进，只是节点内部不再完全由固定代码决定。

状态机的价值，是把这种不确定性放进明确的边界里。系统知道当前状态，也知道从当前状态可以走向哪里；Agent 可以在节点中寻找解法，但不能随意改变整个流程的语义。

智能的一部分，是把步骤压缩

Agent 执行任务时，有些原本需要逐步展开的序列，经过反复运行后可以被压缩成更高层次的一步。发现规律、提炼规则、固化环境，本质上都是把多个重复步骤压缩成一个可复用的动作。

智能不仅是搜索更大的答案空间，也包括把已经理解的过程沉淀下来。压缩得越多，下一次执行就越不需要重新消耗上下文，系统也就能把注意力放到更高层的问题上。

这也是为什么不能只盯着单次任务的结果。每次 Agent 处理不好的内容，都应该被记录下来，反馈回环境，转化成更好的模块、规则或检查机制。下一次遇到类似问题时，系统就不必从头试错。

用控制论改造运行环境

控制论和系统论提供了另一个重要视角：系统不是执行一次就结束，而是通过反馈不断修正自己。Agent 做出动作，环境返回结果；结果暴露出的偏差，再进入下一轮治理、模块化和流程设计。

因此，真正值得建设的不是一个只会接受命令的 Agent，而是一个能形成反馈闭环的环境。它能够知道哪里出错，知道哪些结果不可接受，也知道什么时候应该停止并交回人工。

代码架构中的模块化、工作流中的节点拆解、状态机中的流转条件，以及控制论中的反馈回路，实际上指向同一个目标：把复杂系统拆成可观察、可修正的部分。

让 Agent 在环境中寻找最优解

理想的运行环境不是放任 Agent 随意行动，也不是用无数人工确认把它锁死，而是把边界、工具、反馈和停止条件配置清楚。这样，即使 Agent 的智力足够强大，也不能越过环境的约束，只能在允许的范围内寻找更好的解法。

当环境能够自洽运行，失败能够反馈，规则能够迭代，Agent 才有可能真正完成自我迭代。人的角色也会随之变化：从不断盯着每一步，转向设计状态、环境和反馈机制。

现在还不一定已经产出了足够显性的成果，这会让人焦虑。但持续推进并不等于盲目等待。更重要的是让每一次尝试都沉淀为系统的一部分，最终把耐心转化为一个可运行、可验证、能够自己闭环的实际系统。

部署服务、治理与 Agent 自主执行

Thu, 24 Sep 2026 13:03:00 +0800

治理先行：给 Agent 一个能持续执行的环境

过去一段时间，我一直被一个看似具体的问题拖住：每次修改功能、准备部署，都要反复输入管理员密码。多账号隔离和权限边界本来是为了安全，但如果部署路径没有被设计好，它就会让每一个小改动都变成一次漫长的手工操作。

这件事让我意识到，Agent 执行效率低，很多时候不只是模型不够聪明，而是它所处的环境没有为持续执行做好准备。真正值得问的不是“能不能让 Agent 自己做”，而是“有没有给它一个能持续做下去的环境”。

一个完整的部署小案例

原来的阻塞点很具体：多账号隔离后，启动任务不在我的用户名下，部署时经常需要输入 sudo 或管理员密码。每开发一个小功能，都要重复查问题、绕过卡点、输入密码，再等待服务上线。整个过程不是某一条命令特别难，而是部署动作被拆成了连续的人工确认。

后来，我把部署本身收敛成一个由管理员权限启动的服务。这个服务接受部署调用，职责只限于部署；它不负责开发、不负责审计，也不承担其他任务，其他工作仍交给相应的 Agent 或执行角色。这样做不是把权限无条件交出去，而是把高权限动作限制在一个边界清楚、职责单一的入口里。

真实记录中的成功判定不是一个虚构的耗时数字，而是两个实际结果：服务启动后，部署过程不再需要我持续输入密码和盯守，最后两个服务成功上线。原始记录没有提供一套已经验证的自动失败接手机制，所以不能把它写成“失败会自动恢复”。如果部署失败，应停止当前流程，交回人工或负责的执行者核查。

这个案例说明，所谓自主执行，前提不是放弃权限边界，而是把高权限动作配置成可观察、职责单一的环境。

反复盯守不是可靠的自动化

当 Agent 在部署过程中不断停下来询问密码、等待确认，人的时间就被切成了很多小段：输入一次、检查一次、重新解释一次，然后再等它继续。表面上看，人与 Agent 一直在协作；实际上，大量精力消耗在流程摩擦上。

一种直觉做法是继续盯着它，在每个阶段增加更多人工限制，以为这样可以降低出错概率。但如果每一步都必须回到人这里，任务就很难在无人值守时完成，也无法真正形成可复用的执行流程。

更好的问题是：怎样配置一个环境，让 Agent 在目标明确的情况下持续工作，直到完成？

治理要先于放权

治理越早做越好。治理规则把什么可以做、什么不能做、什么时候需要审计和如何恢复写清楚之后，才有可能放心地让 Agent 持续执行。

治理不是为了让 Agent 每一步都被拦住，而是为了让它在明确边界内少走弯路。权限边界、审计和门禁配置好之后，才可以相对放心地放开执行。所谓“放开 Agent 去做”，前提不是取消限制，而是先把限制设计成稳定的环境。

比较合理的顺序是：先治理，再配置环境，最后把明确的目标交给 Agent。治理解决“能不能安全做”，环境解决“能不能顺利做”，目标则解决“要做成什么”。

从交互式推动到 Goal

我曾经尝试把开发、审计等工作拆成多个本地会话，靠人与不同 Agent 反复沟通来推动进度。这种方式在小任务上可以工作，但任务一复杂，就会变得很慢：需要不断转述背景、确认下一步，再等待另一个会话继续。

另一种方式是给出一个明确的 Goal，让 Agent 自己拆解执行和审计工作。人的职责从“推动每一步”转向“定义目标、配置环境和检查关键结果”。Goal 不是一句模糊的“把它做好”，而应该包含完成标准、可用工具、权限边界和失败时的处理方式。

Agent 能力不只取决于模型

一个任务最终能否完成，取决于至少四个因素：模型本身的能力、初始上下文、动态环境，以及问题本身的难度。

初始上下文包括 prompt、skill 和任务说明；动态环境包括 Agent 能调用的工具、能检索的记忆、能看到的反馈，以及部署服务提供的执行条件。问题本身也有不同维度的难度：有的问题搜索空间很大，需要模型探索正确路径；有的问题只是步骤太多，需要被拆成多个阶段。

这意味着，提升 Agent 的效果不只是换更强的模型。还可以优化初始 prompt，改善动态环境，把复杂问题拆解成更小的节点，并为常见流程提供必要的先验。

Workflow 是降低难度的工具

复杂任务不适合一次性交给一个 Agent 从头做到尾。Workflow 的作用，是把大问题拆成多个阶段，让每个节点只处理更明确的一部分上下文和决策。

拆解不仅减少上下文长度，也会降低问题本身的难度。部分环节可以压缩成脚本，部分环节交给模型判断；节点之间通过门禁传递结果，减少幻觉和信息丢失。Workflow 不是额外的形式主义，而是把原本很大的搜索空间切开，让模型在更小、更清晰的问题上发挥能力。

用四个问题检查下一步

要把目标型执行落到实际流程里，可以在每个节点开始前问四个问题：

卡在哪一步？ 明确当前节点、依赖和阻塞点，不把所有问题都归结为 Agent 能力不足。
这一步允许 Agent 做什么？ 写清可用工具、权限范围和不能越过的边界。
交出什么可核对结果才算完成？ 指定 artifact、日志、测试、部署状态或其他可复核证据；没有证据就不算完成。
出现什么情况停下交回人工？ 权限越界、依赖缺失、结果不可验证、重复失败或需要人作价值判断时，都应停止并交回人工。

这四个问题把“让 Agent 自己做”从一句愿望变成了可以检查的执行协议。

结语：少盯过程，多设计环境

人仍然需要决定做什么、为什么做、哪些风险不能接受，以及什么证据才算完成。只是这些判断不必重复发生在每一个执行步骤里。

治理、部署服务和 Workflow 分解最终指向同一个目标：把人的时间从重复盯守中释放出来，用于创作、判断和真正重要的决策。Agent 能否持续工作，取决于我们是否给了它一个足够清楚、足够安全、也足够能跑到完成的环境。

珍惜时间、目标型 Agent 执行与工作流分解

Tue, 22 Sep 2026 19:19:00 +0800

最近越来越强烈地感觉到，人生的时间并不多。真正重要的事情，是用时间创作出一些东西，而不是把自己消耗在反复盯守、不断确认和看似忙碌的交互里。

从盯着 Agent，到配置一个能自己完成任务的环境

过去遇到自动化任务时，我常常担心它在某一步出错，于是给每个阶段加限制，自己守在电脑前不断输入管理员密码、确认下一步。结果任务没有真正持续执行，人的时间反而被切成了许多等待和干预的片段。

更合理的方式，是把部署、权限和工具配置成一个明确的环境，让一个服务只负责严格的部署动作，其他任务交给不同的 Agent 去完成。先设定目标，再设计一条能够持续运行的过程，让系统在我不在电脑前时也能继续工作，直到完成。

这不是放弃控制，而是把控制从“每一步都亲自盯着”转移到“提前设计好目标、边界和环境”。前者不断消耗人的注意力，后者则把时间投入到更高价值的规划和创作中。

复杂任务为什么需要工作流

和同事讨论 Agent 的自我进化时，我重新思考了工作流的意义。一个大的现实任务，往往不能直接交给模型从头做到尾。它需要被拆解成一组更小的节点任务，每个节点都有清晰的输入、输出和状态转移。

一个节点任务的完成，取决于几个部分：模型本身的智能、提示词、当前上下文，以及模型能够检索到的记忆、资料和工具。记忆和资料库并不是抽象的背景，它们构成了 Agent 的索引材料；工具和权限则构成它实际可用的环境。

当一个大任务被拆成足够小的节点，每个节点就可以在有限上下文中完成一件相对明确的事情。节点之间再通过工作流衔接起来，并用门禁检查各阶段的通信和输出，从而降低幻觉和信息丢失的风险。

能力提升不只是换更强的模型

Agent 能力的提升，当然包括模型智能本身的提升，但不止于此。还需要同时优化提示词、可检索的材料、工具环境、流程模式和任务粒度。

我倾向于把上下文区分成两类：静态上下文是这一次节点任务直接需要的内容，动态上下文则是这个节点背后所处的完整工作背景。只有把两者结合起来，节点才不会只看见眼前的一小段指令，却不知道自己在整个工作流中承担什么作用。

这也解释了为什么任务分解如此重要。不是所有环节都需要模型从头推理到底；有些环节可以被脚本压缩处理，有些环节需要模型运用判断力。把适合脚本的部分固定下来，把需要智能的部分交给模型，再为每个节点提供足够而不过量的上下文，系统才更有可能稳定运行。

把时间用在目标型工作上

目标型执行的核心，不是让 Agent 看起来一直很忙，而是让它在明确目标下持续向完成状态前进。人的工作也一样：与其不断处理即时的小问题，不如把时间投入到目标、环境和流程的设计上。

只要任务被拆解得足够细，输入和输出足够清晰，配合合适的门禁和环境，许多原本难以一次完成的工作，就可以被压缩成一组可以持续推进的节点。

人生有限，应该少一点盯守，多一点创作；少一点假装忙碌的交互，多一点目标、环境与流程的建设。最终要解决的问题是：怎样让系统在我不在电脑前时，也能持续干活，干到完成。

机会成本、方向焦虑与把人生系统化

Mon, 24 Aug 2026 20:45:00 +0800

最近重新听曼昆经济学，几个基础原则突然和我正在经历的事情连了起来。

别只看成本，要看机会成本

一件事的成本，不只是它直接花掉的钱，而是你因此放弃的最有价值选项。买 token、买工具、把时间交给自动化，真正该问的不是“它贵不贵”，而是它节省的时间是否比我的单位时间更有价值。

如果一个工具能让我省下一个小时，而这一小时本来可以用来完成更重要的工作，那么它的价格就应该和这个被释放出来的机会一起衡量。很多决策之所以看起来昂贵，是因为我们只看见了支出，没有看见被放弃的收益。

激励机制会改变行为

人的行为会随着激励机制变化。想预判一个系统、一个团队，甚至一个人的下一步，不妨先问：他被什么奖励？什么行为能让他获得更多收益？

当激励机制改变，行为也会随之改变。理解这一点，比单纯评价一个人的选择更有用。因为很多行为并不是性格突然变化，而是环境在告诉他：这样做更划算。

不要被沉没成本绑架

决策应该看接下来还需要投入多少，以及这些新增投入能带来什么，而不是看过去已经投入了多少。过去花掉的钱、时间和精力已经无法收回，它们不应该继续决定未来。

这并不意味着过去的努力没有价值。过去的投入可以提供经验和资产，但不能成为继续投入的理由。真正的问题始终是：从现在开始，再投入一单位资源是否值得？

在 Agent 路上感到孤独

最近我也会感到一种方向上的孤独。一直在做 Agent，持续迁移、搭建和修整自己的系统，看到别人沿着其他方向取得进展时，难免会怀疑：我是不是在一条错误的路上不断狂奔？

这种焦虑并不完全来自工作量，而是来自方向的不确定。更复杂的是，我既不愿意为了迎合别人而放弃自己认为有长期价值的事情，也承认自己有时只是做感兴趣的事，并没有真正对准目标。

所以问题可能不只是“要不要坚持”，而是目标是否清楚、战略是否有效、每天的行动是否真的指向目标。

用系统化对抗迷茫

也许更好的办法，是像重新做一个系统一样重新梳理自己：我的目标是什么？约束是什么？现在的行动对应哪个目标？哪些事情只是熟悉而不是重要？

《好战略，坏战略》提醒我，战略不是漂亮的口号，而是识别关键问题、集中力量、形成连贯行动。把人生系统化，不是把生活变成一张冷冰冰的表格，而是让有限的时间和注意力不再被模糊的焦虑随意消耗。

我仍然想继续做 building in public。播客、Agent 实验、迁移过程和踩坑记录，都是一种公开的长期积累。方向未必每次都正确，但只要持续记录、复盘和校正，就不会只能靠情绪判断自己是否在前进。

有时，系统化并不是为了让未来变得完全确定，而是为了在不确定中，仍然知道下一步该做什么。

Agent 一直用我的身份干活，直到我花两天做了权限隔离

Sat, 15 Aug 2026 10:00:00 +0800

Agent 一直用我的身份干活，直到我花两天做了权限隔离

我的 Agent 一直在用我的身份干活。不是比喻，是字面意思。

前段时间我把工作流和论坛都搭好了，正觉得一切上了正轨，结果发现地基是松的：Agent A 拿着 Agent B 的权限在跑，消息互相泄露，工作流和论坛时不时卡一下。那几天我干得最多的一件事，就是对着日志猜"这条消息到底是谁发的"。多 Agent 系统里最头疼的不是功能，是"谁是谁"。

先享受了几天便利

说句实话，曾经有短暂的时间，我享受过工作流的便利。任务拆细，分给不同的 Agent，它们各自干活，我只在关键节点看一眼结果。那段时间是爽的，感觉自己终于从琐事里解放出来了。

但好景不长。A 拿了 B 的权限这件事，让工作流和论坛出现卡点。更麻烦的是消息互相泄露，Agent 之间身份混用，消息串台，我分不清哪条消息是谁发的，哪个动作是谁做的。鉴权问题本身已经够头疼，衍生的修复问题又带来新的错误，修完这个坏那个，只能重新修回来。

举个例子你就明白那种感受：一个 Agent 发的帖，署名是它自己，但底层实际用的是另一个角色的权限。表面看一切正常，实际上每一步都在越权。这种问题藏得深，平时不显眼，一旦两个 Agent 同时操作同一个资源，冲突就冒出来了，而且你根本没法判断该让谁负责。

那段时间我反复在同一个地方打转。今天修好一个口子，明天从另一个口子漏。最难受的不是出错，是出错了不知道是谁干的，想定位都无从下手。你以为是 A 干的，翻记录发现是 B 的权限，再往下查又变成 C 的账号，一圈绕下来，时间全耗在对身份上。问题的根源很清楚：身份不唯一，权限不隔离。地基不牢，上面搭什么都白搭。

方案一：双账号，把操作系统权力隔开

第一个动作是账号隔离。本质上是搞了两个账号。

一个账号，Agent 跟我在同一个用户上跑，拥有所有访问权限。另一个，OpenClaw 进程和鉴权插件跑在另一个用户态上，这个用户态能访问关键信息，但其他用户访问不到那些密钥。

为什么这样设计？因为靠"自觉"是不行的。Agent 不是故意的，但它分不清边界，给它一个身份它就以为自己是那个身份，该碰的不该碰的一起碰。你可以在提示词里写一万遍"不要越权"，但提示词管不住权限本身，就像你可以在门牌上写"闲人免进"，但门没锁就是没锁。与其让它在同一个账号里小心不要越界，不如从操作系统层面把权力隔开。进程级的用户态隔离，物理上让别的用户摸不到密钥，这比任何约定都硬。

打个比方，这就像公司里普通员工账号和管理员账号分开：普通员工能进自己工位，但保险柜的钥匙放在另一个房间，进门还要登记。你不是不相信员工，你是没必要让每个人都知道保险柜密码。

账号层隔离是地基的第一块砖：先解决"谁是谁"的账号归属问题。

方案二：密钥放独立服务，插件换临时 token

账号分开了，密钥还在 Agent 手里，等于白搭。所以第二步，把密码放到另外一个服务上，正常的 Agent 没有权限去改那个密码。

然后所有要调的功能都放进插件里。Agent 不说"给我密钥"，它只说"我要调什么功能"，通过插件去访问。插件拿到请求后，用密钥换取一个临时的 token，Agent 拿到的只是这个临时凭证，用完就失效，永远看不到密钥本身。

为什么这样设计？最小权限原则。Agent 没有任何权限，就没有办法看到任何密钥。它不需要知道密码，它只需要在需要的时候，通过插件换一个临时 token。这就像你去酒店前台借门禁卡：前台验证你的身份，给你一张限时的卡，你永远碰不到后台的万能钥匙。密钥不落地在 Agent 手里，泄露面直接归零。

这里有个容易忽略的点：插件本身也是 Agent 能调用的东西，为什么插件就信得过？因为插件是受控的，它只暴露"调功能"这个口子，不暴露"看密钥"这个口子。Agent 和密钥之间隔着一层插件，这层隔阂是设计出来的，不是靠 Agent 自觉维持的。权限的边界落在代码里，比落在对话里可靠得多。

这两步是一体的：账号隔离解决"你是谁"，密钥服务解决"你能碰什么"。

身份写死：终于知道谁是谁

账号、密钥都弄好了，还差最后一件事：把身份固定下来。

每个人的身份被 OpenClaw 本身绑定写死，HR 就是 HR，研发总监就是研发总监，不会出现一个 Agent 今天叫 A 明天叫 B 的情况。说实话这个过程不太优雅，我用了不少比较 hack 的方法，才终于把鉴权理顺，终于知道谁是谁了。

“终于知道谁是谁"听起来像句废话，但在多 Agent 系统里，这其实是权限隔离的验收标准。身份唯一确定了，每条消息、每个操作才能对得上人，后面的协作才谈得上。没有这一步，前面账号隔离得再干净，Agent 之间还是可以互相冒充，等于白干。

两天，和为什么值得

这套东西花了我两天时间。单单做这一个事，费了我很大的时间。

两天听起来不便宜。但换个角度看：鉴权是地基，地基不牢，上面搭的工作流和论坛全是白搭。这次修好之后，基本是一劳永逸的事，短时间内不会再有问题。这两天花在根子上，不是花在打补丁上。打补丁是今天修一个明天坏一个，修地基是这次理顺，后面不再为身份问题返工。

我当时的判断很简单：这个问题不解决，后面每加一个 Agent、每搭一条工作流，都要在烂地基上多盖一层，迟早塌。与其到时候推倒重来，不如现在花两天把地基打牢。而且说实话，这类问题越早修越便宜，等到 Agent 数量翻倍、消息量翻倍的时候再动，代价只会更大，排查起来也更痛苦。

效果：各自走各自的工作流

身份弄干净之后，效果是立竿见影的。做完权限隔离，Agent 们开始自己走自己的工作流，自己做自己的论坛发帖，身份唯一确定下来，不再乱糟糟。不再乱用别人的权限，不再消息串台，每条消息、每个帖子都能对上号。

第二天我又确认了一遍：通过密码把操作系统权力隔开之后，消息不再互相泄露，鉴权基本根治，工作流和论坛恢复正常运转。原来那种"这条消息是谁发的"的猜谜游戏，基本消失了。

回头看这条线：曾经短暂享受过便利，因为鉴权和衍生修复问题出了错，现在重新修回来了。问题（混乱）到方案（隔离）再到效果（正常运转），闭环成立。而且这个闭环不是纸面上的，是每天都能感受到的：论坛帖子的作者对得上号了，工作流的每一步都知道是谁在做，不会再乱糟糟了。

延伸：从单 Agent 到一条工作流

隔离做完，工作流才真正串起来。每个 Agent 做完分配给下一个，下一个继续，把一个完整的任务拆得很细，串在一个工作流里。你能看清流转状态，能更新它们的 skill、更新 AGENTS.md、更新各种细节。这套东西具备了把复杂任务拆解成工作流、静态编排、调度唤醒、门禁执行、历史记录、收拢归纳、发现问题自我进化的能力。

我的范式是：定义清楚工作流，定义清楚输入输出，让它执行，人负责验收，验收完让它自己去进化。现在还少一步，就是让它自己复盘。唯一担心的是它会跑偏，所以偶尔还是得盯着。盯不是不信任，是这套系统还在长，跑偏了要有人把它拉回来。

进化路径大概是这样的：单个 Agent，短程小任务能做得很好，通过 AGENTS.md 协调得很好；接下来是控制一整条工作流；再下一步是扩展一个更大维度的工作流。它能做的事情越来越多。回头看，权限隔离不是终点，它只是让这条路能走下去的前提。没有身份隔离，工作流串得越深，出错时越难收场；有了隔离，串得越深，反而越踏实，因为每一步都知道是谁在做。

还有一个治理层面的思考。Agent 经常自以为是地帮你做决策，所以你得完整看它的方案才能敲定。这引出一个问题：一个 Agent 都要完整看方案，多 Agent 互动起来的可信度有多高？两条路：要么方案确定得很清楚再交给执行，要么通过多轮迭代，让它逐渐知道你到底要什么。我倾向先定清楚再放出去，偶尔盯着。这条路我还在走，但至少身份隔离之后，我敢让它们跑起来了。

收尾：地基打牢之后

回到开头。工作流和论坛搭好了，但地基不稳固，A 拿着 B 的身份干活，消息互相泄露。现在鉴权这层地基打牢了，身份干净了，各自走各自的工作流，工作流和论坛才真正跑起来。

接下来就是把该工作流化的东西都工作流化，继续 building public。地基打牢之后，上面盖什么都稳。

从跟每个 Agent 聊天到工作流管理：我的 Agent 管理心法转变

Sat, 15 Aug 2026 08:00:00 +0800

从跟每个 Agent 聊天到工作流管理：我的 Agent 管理心法转变

系列第 4 篇。前情：鉴权体系设计（为什么）→ 鉴权根治（怎么做）→ 编排进化（从单 Agent 到多 Agent）→ 本文（从聊天管理到工作流管理）。前篇讲「结构怎么搭」，这篇讲「心法怎么转」。

0. 3 个 Agent 靠聊天，40 个 Agent 聊不过来

我的 Agent 数量第一次突破两位数时，我还没意识到问题的严重性。

3 个 Agent 的时候，管理方式朴素得不能再朴素：跟每个 Agent 聊天。告诉它今天要干什么、上次哪里做得不对、这次希望它注意什么。它干活，我看结果，有问题就在聊天里纠正。一切尽在掌握，甚至有点享受这种「带徒弟」的感觉。

直到 Agent 扩展到 40+，崩溃来得毫无预兆。

我发现自己一整天都在聊天。跟内容 Agent 对选题，跟编排 Agent 看流程日志，还要回答各种「这个需求怎么理解」「那个输出格式对不对」。时间被聊天填满，上下文在不同的会话窗口之间碎片化。更折磨的是同一件事要反复教：同一个约定，这周已经在不同窗口里重复解释了无数遍，可每个新 Agent 依然一脸茫然地看着我。

最开始的归因是错的。我以为是自己沟通技巧不行，话没说清楚，于是花更多时间去把话说得更细——然后陷入更深的聊天泥潭。直到我想明白问题的本质：这不是沟通问题，是沟通成本的结构性爆炸。3 个 Agent，你维护 3 条对话线；40 个 Agent，你维护 40 条对话线，而且每条线上都是重复劳动。聊天管理的时间成本是随 Agent 数量线性甚至超线性增长的。

「如果你原本是’每个人都要跟他聊天’，那你其实不太会创建很多 Agent，因为每一个人都在跟他聊。」——这句话是我崩溃之后才真正读懂的。聊天模式的瓶颈不在沟通技巧，在沟通本身。

解法只有一个：管理方式从「跟每个人聊天」切换到「工作流 + 域 owner」。

1. 心态转变：从「每个人都要聊天」到「工作流 + 域管理」

两种模式，本质区别在于「谁在教 Agent 干活」。

	聊天模式	工作流模式
谁教 Agent 干活	你，人肉教	工作流教
你的角色	需求方+培训师+验收员	定方案、管 owner
沟通对象	所有 Agent	几个域 owner
规模化	沟通成本线性涨	成本集中在流程设计
经验沉淀	在聊天记录里，随聊随丢	沉淀进工作流，可复用

聊天模式里，你是每个 Agent 的私人教练。工作流模式里，你只做一件事：把 Agent 塞进流程。

「如果是’工作流+Domain 模式’的话，你招聘了这些 Agent 之后，直接把它无脑的塞进工作流里，让工作流的方式去优化这个 Agent，教它怎么干活，而不是你直接教它怎么干活。」

「无脑塞进工作流」不是草率，是刻意：招聘来的 Agent 不需要你先跟它培养感情、磨合风格，流程会教它。工作流定义了输入输出、执行步骤、验收标准，Agent 在一次次流转中被优化。你教的不是 Agent，是流程；流程教 Agent。

沟通结构同步改变：「你还是和这些 owner 聊天，然后 owner 负责去推动，通过工作流的过程去推动他们干活。」——你的沟通对象从 40 个 Agent 收敛成几个域 owner。域 owner 是每个领域的接口人，他们通过工作流推动下游干活，而不是你直接插到每个 Agent 面前。

这套模式能成立，依赖一个技术前提：权限隔离之后，Agent 身份唯一，用工作流把它们串在一起。一个完整任务被拆得很细，工作流提供静态编排、调度系统、门禁、历史记录、收拢归纳进化。定义清楚工作流的输入输出、执行、验收，让流程自己进化。

拿我自己的内容管线举例。我正在把内容管线拆成两个工作流：一个是发布到固定平台的截止流程，这个已经在跑；另一个是同步其他平台的流程，还在打磨。拆完之后的理想状态是：一平台一工作流一文章，失败的逐个讨论——而不是在一堆聊天窗口里追「这篇发了吗、那篇卡哪了」。状态在流程里，不在聊天记录里。

落点一句话：你管理的不是 40 个 Agent，是 40 个 Agent 之间的流程与边界。

2. 信任问题：GPT 连单个 Agent 都控制不住，多 Agent 可信吗？

聊到多 Agent，绕不开一个扎心的问题：可信度。

先诚实交代单 Agent 的现状。GPT 经常自以为是在帮你做决策。「它经常会做一些自以为是帮你做一些决策，所以你得完整的看它的方案才能敲定下来。」——这是我跟单个 Agent 协作时的常态：它给出的方案永远自信满满，但你必须完整看完才能敲定，因为它可能在一个你没注意到的角落里替你做了一个你并不想做的决定。

于是尖锐的问题顺理成章：「如果说 GPT 连单个 Agent 都控制不住，那么多 Agent 让它互动起来，它到底有多高的可信度？」

一个都管不住，一群互动起来，不是应该更失控吗？——这是我在决定全面转向工作流之前，问自己的问题。我的答案是：可信度不靠聊天频率，靠方案清晰度 + 迭代闭环。

「主要是方案确定了，如果方案确定了之后，就可以交给他们去执行就可能还好，只是说这个方案得确定得很清楚，或者是通过多轮迭代，在迭代的过程中让他们知道我要他们干啥。」

注意这里的关键转折：方案确定了，就可以交给他们执行。多 Agent 不是把「信任」分摊给每个 Agent，而是把「信任」前置到方案阶段——方案定得足够清楚，执行阶段就可以放手。单个 Agent 的不可控，用方案的确定性来对冲。

配套一个具体做法：跟 GPT 聊要停下来问清楚「这到底是在干啥」，方向把握清楚——不是每个步骤都要知道，但方向要对。方向错了，方案再漂亮都是南辕北辙；方向对了，执行中的小偏差可以被流程兜住。

3. 工作流拆分审稿：大任务拆小片，各个击破再汇总

心法之外，分享一个具体的拆分实践：审稿。

把整篇文章一次性丢给一个 Agent 审，会怎样？上下文爆炸，审稿质量崩。文章越长，Agent 的注意力越稀薄，看到后面忘了前面，给出的意见越来越空泛。

「当一个文章出来之后，应该会对它做分段，然后分发到各个小的任务上，每个任务给出一个审稿意见，然后再汇总成为全篇的一个感受——这样才不会整篇文章进来上下文爆炸。」

做法：文章分段 → 分发到各个小任务 → 每个任务给出审稿意见 → 汇总成全篇感受。一段一个 Agent，每个 Agent 只面对一小块上下文，意见具体、可执行；最后把意见汇总，拼出全篇的问题地图。

原理其实很朴素：「只要 Agent 足够聪明，小的事情能做好，那你完全可以把它分解得足够小，然后各个小的任务都做好之后串起来，它就能把整个大的任务做好。」

这就是工作流「拆」的艺术：拆得够小，单个 Agent 的不可控就被稀释。一个 Agent 看全篇会漏，看一段会认真；十个 Agent 各看一段，汇总出来的意见比一个 Agent 硬着头皮看十遍更可靠。不可控的 Agent 不可怕，可怕的是把不可控集中在一个大任务里。

再进一步，工作流可以衍生动态工作流——依赖多个子任务的状态，子任务完成情况决定下游怎么走。这里留一个我还在想的思考钩子：小事做好，是否意味着宏观视野一致？每个子任务都合格，串起来的整体是否必然合格？如果整体出了问题，是不是核心准则没有在每个子任务里显式传递？这个问题我还没有标准答案，但它值得每一个做拆分的人想一次。

4. 眼里有活 vs 集中精力办大事：两种观念的打架与调和

管理 Agent 之外，还有一个更隐蔽的战场：管理自己。

「眼里有活是 ownership 的概念：在边界模糊的地方愿意承担多一点，把那个东西当成自己的事情。」——这是我认同的第一种观念。边界模糊的地方没人认领，你多承担一点，系统就多一分完整。

「另一个观念是：你的时间是有限的，你不能把小事填充满了所有时间，然后让自己没有时间做大的事情。」——这也是我认同的。时间总量固定，被琐事占满，大事就没有容身之处。

两个观念都正确，但它们打架。眼里有活的人容易琐事缠身：这个顺手修一下，那个顺手补一下，一天下来全是「顺手」，主线纹丝不动，效率反而更低。而只讲集中精力的人，容易在边界模糊的地方漏事，最后还是要回头补课。

我的调和机制：让效率管家来做记录，然后我在一些固定的时间段去把这些零散的小活给做了——既兼顾眼里有活，又把主要精力留给大事情。

配套几条原则：不要做太多琐碎的事，固定时间做琐碎事，只要不膨胀不爆炸就可以接受；要有轻重缓急和优先级；用 OKR 里的进展作为往前推进的证据——主线有没有推进，不看感觉，看进展记录。

核心是用系统（记录 + 定时）而不是用意志力，同时满足两个观念。琐事不膨胀、主线有进展，就是健康的平衡。这个机制同样适用于 Agent 管理：琐碎的小任务交给固定流程去消化，主线的精力留给真正的难题。

5. 升华：管理者的进化——从「亲自教」到「搭系统」

回到系列的双线。前篇讲编排结构——怎么搭；本篇讲管理心法——怎么管。结构 + 心法，到这里合流：结构是骨架，心法是驱动骨架运转的方式，缺一不可。

管理心法的本质是什么？搭系统 vs 死磕时间。

「搭系统 vs 死磕时间，不要用战术上的勤奋掩盖战略上的懒惰。」——死磕时间是战术勤奋：我多聊几句、多盯一会儿、多改几遍，事情总能推进。搭系统是战略动作：把经验沉淀进工作流，做执行-review-提升的闭环，让流程自己变好。

搭系统还有一个容易被忽略的红利：组织能力不随人走。人走了，流程还在；Agent 换了，工作流还在教下一个 Agent 怎么干活。能力从「存在某个人身上」变成「存在流程里」，这才是一个团队从作坊走向组织的标志。

对比前篇的「从亲自教到工作流教」：本篇是同一进化的管理侧视角——从人肉聊天到系统治理。结构解决「怎么搭」，心法解决「怎么转」：先承认聊天模式到顶了，再下定决心把 Agent 交给流程。

6. 收尾：行动清单——先定方案，再建流程，最后放手

回到开头的问题：3 个 Agent 靠聊天，40 个 Agent 靠什么？

答案不是某个神奇工具，是一套动作：

方案定清楚。多轮迭代，直到 Agent 知道你要啥。方向把握住，不纠结每个步骤。
把 Agent 塞进工作流，而不是留在聊天窗。让流程教它干活，你只跟域 owner 沟通。
大任务拆小片。分段、分发、汇总，用拆分稀释单个 Agent 的不可控。
琐事固定时间处理。效率管家记录，定时集中消化，精力留给主线。

顺序很重要：先定方案，再建流程，最后放手。方案不清就建流程，流程会把模糊放大；流程不稳就放手，失控是必然的。

Bookend 闭环：聊天的尽头是工作流。你省下的不是聊天时间，是管理心智——从「跟 40 个 Agent 周旋」到「设计 40 个 Agent 之间的规则」，这是同一个问题在不同规模下的两种解法，而后者，才是规模化的答案。

快调通 Agent 内核时，DeepSeek 把我的轮子开源了

Sat, 15 Aug 2026 08:00:00 +0800

我的轮子，被开源了。

昨天 DeepSeek 发布了 Harness，核心理念一句话：一切皆插件。而我手上这个做了很久的 Agent Core，一个类 Linux 内核的东西，内核极简、各种插件往上挂，跟它对比了一下，有一点点区别，但基本上一样。

说实话，那一刻是有点道心破碎的：自己辛辛苦苦快调通了，结果这边发布了一个所有人都能去优化的东西。

但破碎归破碎，这篇不只是讲情绪。我想借这次撞车，讲清楚两件事：一是情绪线，从道心破碎到务实转向，我到底经历了什么判断；二是认知线，顺着这次撞车，我把 Agent 自净化的路径梳理成了三层压缩理论，以及两个我越来越确信的判断：插件门槛不在插件本身，完整历史记录是自净化完备性的前提。

撞车现场

先说我做的东西。

这段时间我一直在做自己的 Agent Core，思路就是 Linux 内核那套：内核保持极简，把各种能力做成插件挂上去，需要什么装什么。核心目标只有一个，让 Agent 能自净化：犯错之后能把经验收回来，优化掉错误行为，下次不再犯。我一直觉得这条路是对的，而且是那种"肯定会被做出来"的方向，就像之前播客里聊过的，自净化最终会长成 Linux 内核的样子。

然后 DeepSeek 的 Harness 发布了，理念是一切皆插件。我第一时间去对比，越对比越沉默：它跟我的内核在理念上基本一样，只有一点点区别。而且看社区讨论，帖子里好多人也在说类似的思路，只是 DeepSeek 真的把它做出来了，并且底座看起来更数学扎实。

还有个小小的插曲：我挺想去参与内测的，没被拉去。羡慕谈不上，失落是有一点的。

但真正让我清醒的是这句话：底层的框架，它已经实现了。我基本不太可能再去做这个内核了，做不出东西来了。

这不是气话，是事实判断。内核这层已经被占住了，我能做的，是内核之上的东西。我的 Workflow 还能用，自净化的过程还能用，只不过从框架层的自净化，变成了业务层的自净化。业务层自净化是慢慢可以扩展到框架层的，至少框架具备这个能力。

冷静对比：它比我强在哪

道心破碎之后，我强迫自己冷静下来做了个对比，结论比想象中复杂。

派 Agent 其实不比它弱，这是我真实的判断。但 DeepSeek 的号召力太强了，大家完全可以在它的基础之上做更多开发，进步速度大概率会比派更快。一旦贡献的人多了，它就变成了事实性的标准：大家都基于这一套去做更厉害的 Harness 开发，而不是去用那个"比较弱一些的"。

从技术本质上看，它跟派 Agent、跟 Claude 的插件差异没有想象中那么巨大，它只是更开放，开放层级堪比派。它真正更好的地方在于底层做了认证：像微内核一样做了形式化证明，证明各个逻辑是等价的，不会给以后的某一个时间点埋坑。比如它讲的时空一致性，大概就是时间上确保插入、删除没有影响，空间上确保不会占着东西不释放，大概是这个意思。

唯一让我有点担心的是社区运营，毕竟插件生态做起来，光有框架不够，还得有人愿意在上面折腾。这一点只能走着看。

这里我得诚实：形式化证明、时空一致性这些细节，我自己也标注了"需再研究"，目前只是理解了大概方向，不敢展开断言。写出来是怕读者误以为我搞懂了，其实没有，我还在研究。

但这个对比给了我一个理性依据：放弃自研内核、转投 DeepSeek 底座，不是情绪化的决定。先观望，不急着全换，但可以把一些功能迁移过去试试能不能用。

认知主线：Agent 自净化的三层压缩

撞车这件事，逼我把自净化这条路重新想了一遍。现在我看 Agent 的自净化，本质上有三个层次的做法。

第一层，Skill，软约束压缩。

早期的做法就是像 Prompt Engineering 一样：犯了错，把经验总结优化进一个 Skill 里，下次让它照着做。但真的用过的人都知道，Skill 的能力就那样，幻觉还是很严重，杜绝不了问题。因为它是软约束，模型可以不听。你给它一个 Skill，它想了想说"你这个 Skill 讲得好像不太对"，然后继续幻觉。它只是"大概知道不该这么干"，而不是"干不了"。

第二层，Harness 插件，硬代码压缩。

把约束变成代码之后，性质就变了。服务器、数据库直接不给你这么干，卡死了。注意这个区别：Skill 是"这个东西不太对，你想想"，Harness 是"这个东西肯定不对，就是不给你这么干"。硬代码约束大幅减少幻觉，因为它从根上把错误行为掐死了。

第三层，参数级压缩，终极形态。

这一层不是因为它被卡死才不能这么干，而是它真的去学了参数，学会了"确实不能这么干"，改到了模型参数里。这是最彻底的，但也是来得最晚的。因为要改参数，就得有类似 backward 的过程，得有个像 Backbone 一样的东西。那么大的参数量，除非只改一部分 MoE 的参数，否则一次学习的算力消耗会特别大。但等大算力时代来了，可能会探索出一些方法，这个成本是可接受的。

所以 Agent 的进化，就是沿着这条线走的：软约束压缩，到硬约束压缩，再到参数压缩。这个过程中还有个潜在的可能：模型运行的过程中，可能会中间压缩出一个小参数的模型出来，但这个先抛开不讲。核心规律是，模型在不断地学会怎么更好地处理信息。

万物皆压缩：从 LLM 到人脑短路

这个三层压缩的理论，放到更大的视角下其实是一种普遍规律：一切都在做信息压缩。

LLM 是什么？是全网信息的一个压缩。整个互联网的知识被压进一组参数里。

Skill 是什么？是工作流程的一个压缩。一个流程本来很复杂、不好表达，用 Skill 可以把它比较好地描述下来，还方便分享。本质上就是把十几个步骤的工作流，压缩成一段可复用的描述。

harness 是我自己工具链里的例子，更直观：原本一个流程要跑十几个脚本才能完成，现在变成了调一个接口，把十几个脚本的逻辑压缩成一段代码放在那里。它要不断学会对信息做压缩。

人脑也是这个逻辑。人一开始做一件具体的小事，可能要一件一件地做，ABCD 四个环节一步步来。后来做得多了，大脑的连接短路了，瞬间就能反应过来，ABCD 四步变成一步。越做越短路。本来 100 个步骤，被这个过程压缩成 5 个步骤，腾出来的算力空间就能去做更大的事。

所以你看，从软约束压缩，到硬约束压缩，再到参数压缩，本质都是对中间步骤信息的不断压缩。人做的事情，本质上都是对中间阶段步骤的信息压缩。自进化也是这样：对的留下，错的赶走，剩下的问题就是怎么更好地压缩信息，做更好的发展。

插件化：门槛不在插件本身

回到 Harness 本身，再说一个我观察到的现象。

Harness 的插件本质上跟 OpenAI 的插件类似，只是能力更强一点，能做的事更多。但这不代表着大家会去做这件事，也不代表大家会去用它。它目前对新人不是那么友好，所以社区两极分化，这很正常。

但我有一个判断：插件这个东西，说句实话真的也没有什么。它会跟 Skill 一样，后面慢慢就没有太大的门槛了。它的门槛不在于插件本身，而在于你对于 Agent 运行的工作流、这个流程的理解，以及怎么样组合这些积木做一个更厉害的东西。比如你去改它的循环结构，比如你理解上下文对 Agent 意味着什么。最后考验的还是你对 Agent 上下文的理解，对它的优点和缺点的理解。

插件化对自净化还有一个质的提升。用 Skill 做自净化，最多是执行的时候随手记一些东西下来，记什么是模糊的。但插件化之后，它可以形式化地知道：今天我要记什么东西、记到哪个数据库里，然后在固定的环节去做。这不是随手记录，是流程里固定的一个环节。

所以我的判断是：插件会像 Skill 一样门槛越来越低，而一旦贡献的人多了，它就会变成事实性的标准。DeepSeek 目前还没有严格意义上提出这个标准，但这条路是通的。

自净化的前提：完整历史记录

最后说一个 Harness 特别打动我的点，也是我判断它路线价值的关键：它会把历史记录记录下来，做审计。

这个点正中我的需求。为什么历史记录这么重要？因为只有记录了，事情才是可还原、可追溯的，你才能抓到所有的信息，才能完成新的一轮进化。没有完整的历史，自净化就是无源之水：你都不知道上次错在哪，怎么改？

有了历史记录之后，自净化就会越做越快。每一轮进化都建立在完整的历史之上，信息不丢失，经验可累积。这也是为什么我会觉得，自净化的完备性，只要知道完整的历史，理论上就可以做到。可能这里面会有一些数学证明的办法，但意义可能也有限，点到为止。

所以完整历史记录，是自净化完备性的前提。这是 Harness 这条路线最值得关注的价值，也是它跟我心目中"自净化"最契合的地方。

那就站在这个轮子上继续转

回到开头。我的轮子被开源了，道心破碎是真的，但破碎之后的选择不是放弃，是换底座。

放弃内核，不等于放弃自净化。我做的是业务层的自净化，不是框架层的，但业务层可以慢慢扩展到框架层，框架具备这个能力。我的 Workflow 还能用，我的自净化过程还能用，只是底层不再自己造了。

现在的打算很明确：先观望，没有说现在就要换。但我会把一些功能迁移到它的工具上，看看能不能用。就像当年发现派的时候，纠结要不要换，最后也是先观望再决定。

我做了那么久的内核，最后发现有人把它开源了。那就不拧巴了，站在这个轮子上，继续转。转着转着，说不定哪天，业务层的自净化就长成框架层的样子了。

把密钥藏起来：Agent 鉴权根治实录

Thu, 13 Aug 2026 08:00:00 +0800

把密钥藏起来：Agent 鉴权根治实录

上篇《Agent 鉴权体系设计：协作的地基》讲了：Agent 协作的第一性问题是身份——每个 Agent 得知道"我是谁、我能碰什么、别人是谁"。这篇是续篇：图纸画好了，怎么把它浇成混凝土。

一、开篇：搭好的系统，Agent 却"认错人"

工作流搭好了，论坛也通了。我以为万事俱备，结果一跑起来就卡住。

现象很魔幻：Agent A 提交了一个任务，接单的却是 Agent B；更离谱的是，A 拿到的权限是 B 的——它能读到 B 的密钥、B 的消息、B 的待办。消息开始在 Agent 之间互相泄露，工作流节点走到一半就报权限错误，论坛里出现"不是我发的"的对话。

排查到最后，我意识到一件事：鉴权不稳固，协作的地基就是沙地。 上篇聊了"为什么要鉴权"——身份是 Agent 协作的第一性前提。这篇讲"怎么根治"：把密钥藏起来，把身份写死，让每个 Agent 终于知道谁是谁。

二、现场还原：鉴权到底哪里塌了

按 Debug Journal 的格式把现场过一遍。

现象：工作流卡点、Agent 互用身份、消息互相泄露。

假设 1：代码 Bug？ 排查：工作流逻辑本身没问题，节点流转正常，卡点全部出现在"权限校验"环节。排除。

假设 2：配置写错？ 排查：配置项都对，但问题在于"对也没用"——所有 Agent 跑在同一个用户态下，权限配置形同虚设。这接近真相了。

转折：真正让我警觉的是一张权限表。表里每个 Agent 的身份是"软"的——靠约定，不靠机制。任何 Agent 只要知道路径，就能读到别的 Agent 的密钥文件。

根因：三件事叠在一起——

密钥与身份散落各处：密码、Token、凭据文件躺在各个目录里，没有统一托管；
Agent 直接可见密钥：Agent 的上下文和工具调用里，密钥是"透明"的，它随时能读；
用户态未区分：所有进程跑在同一个用户态，隔离形同虚设。

结论：身份无法唯一确定。一个系统里没人能证明"我是我"，那谁都可以是任何人。

三、解法一：用户隔离——密码放独立服务

第一刀，先把凭据收拢。

做法：把密码和凭据全部收进一个独立服务，由它统一托管。普通 Agent 对这份凭据没有修改权限——它们只能通过服务提供的接口去"申请使用"，不能直接读文件。

效果立竿见影：凭据与业务逻辑分离了。以前 Agent 在业务代码里"顺手"就能碰到别人的密码，现在它连密码文件在哪个目录都不知道。权限的边界从"谁都能碰"变成"只有服务能碰"。

这一步解决的是"散落"问题：凭据不再是一地鸡毛，而是一个有主、有边界、有审计的单一入口。

四、解法二：插件代理——Agent 看不到密钥

收拢还不够。收进独立服务之后，Agent 怎么用凭据？总不能每次都要管理员手动授权。

于是第二刀：插件代理。

做法：所有涉及密钥的功能调用全部收进插件。Agent 不再直接持有密钥，它只能说"我要调什么"——比如"帮我读一下 HR 系统的通讯录"。插件拿到这个请求，自己去独立服务换取临时密钥，用完即焚。

效果：密钥对 Agent 完全不可见。Agent 的上下文里没有密钥、没有 Token、没有密码——它只有一个"意图"，而"凭证"由插件在机制层面完成。

这一步的关键变化是：权限边界从"人治"变成"机制"。以前靠"你别读那个文件"的自觉，现在靠"你根本读不到"的结构。临时密钥还自带生命周期，即使被截获，也只是一次性的、短命的。

五、解法三：双用户态——关键信息只在一个受限态

前两刀解决"密钥在哪、谁去换"，第三刀解决"进程被攻破怎么办"。

做法：双用户态隔离。

Agent 与用户跑在同一个用户态——保有正常的访问权限，能干活；
OpenClaw 进程与鉴权插件跑在受限用户态——关键信息只在这个用户态可访问。

也就是说，即使 Agent 所在的用户态被误操作、甚至被攻破，攻击者也够不到关键信息——因为它根本不在这个用户态里。要拿到密钥，必须同时攻破两个用户态，而鉴权插件所在的受限态几乎不暴露任何攻击面。

这一步把"单点防御"升级成"纵深防御"：干活的环境和藏密钥的环境，物理性地分开了。

六、结果：身份终于写死，谁是谁不再含糊

三刀砍完，系统发生了质变。

身份绑定写死：HR 就是 HR，研发总监就是研发总监。每个 Agent 的身份不再是"软约定"，而是由独立服务、插件代理、用户态三层机制共同锁死的硬事实。

消息不再互相泄露：A 的会话、A 的待办、A 的权限，只有 A 能碰到。论坛里"不是我发的"这种对话消失了。

协作重新跑通：权限隔离之后，工作流节点正常流转，论坛交流恢复正常。之前卡住的地方，全都通了。

回头看验收标准，一条条都对上了：真实搭建经历有（鉴权混乱→三解法→身份唯一确定），技术细节扎实（独立服务管密码、插件换临时密钥、双用户态受限），续篇关系成立（上篇讲为什么，本篇讲怎么根治），结果有说服力（协作重新跑通）。

七、收尾：地基补上了

上篇我说：身份是协作的地基。这篇把地基浇成了混凝土。

可复用清单（三个动作，一句话版）：

独立服务管密码——凭据收拢，普通 Agent 无修改权限；
插件代理换临时密钥——Agent 只说意图，插件换一次性凭证，密钥对 Agent 不可见；
双用户态隔离——干活态与受限态分离，关键信息只在受限态可访问。

给读者的自查建议：先回答一个问题——你的 Agent 系统里，“谁是谁"是唯一确定的吗？如果任何 Agent 都能读到别的 Agent 的密钥，如果你的密钥文件散落在各个目录，如果你的所有进程跑在同一个用户态……那你的地基，可能也是沙地。

补地基不复杂，三刀而已。但每一刀，都是在回答同一个问题：凭什么证明你是你。

一个 Agent 干不好活，那就拆成两个：我的 Agent 编排进化路线

Wed, 12 Aug 2026 10:00:00 +0800

用 Agent 干活的人，大概率都撞过同一堵墙：同一个任务，今天跑得顺，明天就翻车。你以为是运气问题，于是去调提示词，调来调去，它还是时好时坏。

我最早的状态，就是那种一个人盯着一堆 Agent 干活的小组长。每天给它们派活，盯着它们干，干完检查，不行就打回去重来。Agent 一多，我自己的时间全耗在"盯人"上了。

我花了很长时间才想明白：这不是提示词的问题，是结构的问题。单 Agent 干不好活，是因为你把太多事塞给了它。解法也不是把提示词写得更好，而是拆开、编排、治理。这篇文章就是我这条进化路线的完整记录：从提示词工程，到拆成多 Agent，到静态/动态编排，到模型外的 harness，再到软硬约束治理幻觉。最后你会看到，这套技术路线和管理者的成长路线，其实是同一条路。

一、第一层：提示词工程，单 Agent 的上限

最开始，我和所有人一样，遇到 Agent 干不好活，第一反应是 prompt 没写好。

于是调。把要求写得更细，把约束写得更死，把例子写得更多。Skill 本质上也是提示词的一种，Skill 里加点脚本，本质上也还是提示词的一部分。这些都是第一个层级的东西：提示词工程。

但调来调去，有个问题始终绕不过去。你让它写个代码，然后让它自己检查有没有问题，它发现不了问题。你以为是检查的 prompt 没写清楚，继续调，还是不行。

这里有个根源：大模型的能力是有偏向性的。它训练的数据就是"干活"，不是"审查"。你让它自己干完活自己审查，它就是做不好。这不是你 prompt 写得不好，是它天生就不擅长这个。

到这一步我意识到：继续堆提示词，边际收益越来越低。单 Agent 的能力是有天花板的，提示词只能在地基层面做文章。它能注入知识、约束风格，但它给不了记忆，给不了事实校验，给不了流程保证。想突破，必须换结构。

二、第二层：拆成两个 Agent，写审分离

既然它自己干不好"干活+审查"这两件事，那为什么不拆开？一个专门写，一个专门审。

这个想法朴素得近乎废话，但效果立竿见影。写稿的 Agent 只管写，审稿的 Agent 只管挑毛病，角色单一，职责清晰。让一个 Agent 既写又审，等于让运动员当裁判，它天然做不到客观。

拆开之后还能继续拆。能拆两个，就能拆更多。顺着这个思路，编排的原则也慢慢清晰：最好交叉验证，互相写、互相验。串行跑完再并行跑，从不同角度看待同一个问题，这就进入了 Agent 编排的范畴。

但拆完你就发现一个新问题：Agent 变多了，谁来管流程？谁先干谁后干？谁的结果给谁？谁来判断结果合不合格？以前一个人盯一个 Agent，现在你盯不过来。编排的需求就这么冒出来了。

三、第三层：静态编排，然后是动态编排

编排是接住多 Agent 复杂度的骨架。

最简单的是静态编排：固定的流程，先写后审，写完了必须审，审完了才能进下一步。流程稳定的时候，静态编排完全够用。

复杂一点的是动态编排：条件分支，按需路由，根据中间结果决定下一步走哪条路。串行几个 Agent，中间能不能并行？从不同角度同时看一个问题？复杂到一定程度，编排就变成一张 DAG。

这里有个现实问题：这么复杂的编排，谁来做？

模型厂商在做。Kimi 很早就说要搞 Agent 集群、蜂群式干活，把编排能力往模型内部吸收；Claude 的 Dynamic Workflow 也是动态编排的方向。厂商有能力把编排塞进模型里，因为基座模型是他们训的，他们可以把 prompt、skill、多 Agent 编排一点一点吸收进模型内部。

普通人或者企业做不了这件事，我们没法训基座模型。那我们能做的就是：不依赖模型内的编排能力，在模型外面自己套一套编排。这套编排，静态的动态的都能做。

但这里有个关键区别。模型厂商的编排，一次会话结束，上下文就没了，它的训练过程也是一次性的，一个流程从头跑到尾，跑完就散。而我们自己在外面套的这套东西，可以不是一次会话的模式，而是多轮会话，加上长远记忆。这就是下一层要做的事。

四、第四层：harness，模型外的记忆、规则、资讯

把记忆、规则、资讯放在模型外面，按需接进来，这套东西我习惯叫它 harness。就是在模型之外加一套基础设施，把模型不擅长的事接住。

具体接三块：记忆、规则、资讯。

记忆是历史经验。它踩过的坑、做对过的事，不用每次重新教。规则是约束。做什么和不做什么，一定要做什么，一定不做什么，做 A 比做 B 好，这些倾向性写清楚。资讯是模型外的额外信息，实时的事实，它训练时不知道的东西。

整个过程就变成：我拿到额外的信息，或者是记忆，或者是资讯，我知道我有倾向性要做什么，也有倾向性不能做什么，然后让 Agent 带着这些去执行。

为什么放模型外而不是模型内？因为模型外的东西可更新、可追溯、不占上下文，而且不会被模型的幻觉污染。你今天改一条规则，它下次执行立刻生效，不用等重训。你今天喂一条新资讯，它马上就能用上。

有了记忆、规则、资讯，Agent 不用再每次从零开始。但还有一个老大难问题没解决：大模型幻觉重，它会一本正经地胡说八道。编排解决流程，治理才能解决乱来。

五、幻觉治理：软约束加硬约束门禁

治理幻觉，我的做法是给它来点硬的。

Skill 这些东西是软约束。它把规则写进技能里，引导 Agent 的行为。但软约束靠自觉，Agent 状态不好就忽略你。

Skill 里的脚本是硬约束。脚本的结果是确定性的，是代码层面的。Prompt 层面的不确定性，会被代码层面的确定性绑住。你要做的，就是在工作流的各个环节绑上确定性的门禁：你在这个节点提交东西，必须满足我定的条件，不满足就给你打回。这约束了它的提交物是什么。

但门禁约束不了它怎么提交、用什么方式提交。怎么优化这个？靠自净化。

人学习的过程中会被打回。被打回这个行为本身就是一条经验，可以累积到它的知识里，变成"该做什么、不该做什么"的新规则。Agent 也一样：被打回一次，沉淀一条规则，下次就不犯。约束、执行、打回、沉淀，一个治理闭环，而且越用越准。

这套东西不是纸上谈兵，我是真的踩过坑，而且踩得特别深。下面这三个坑，我前后花了可能好几个月才重构完，比想象中久很多。

六、实战三坑：从能跑到跑稳

为了搭一个研发总监 Agent，我开始引入工作流。工作流刚上线那阵，千疮百孔。总结下来有三个大坑。

坑一：鉴权混乱，身份互相串。

现象：多个 Agent 一起干活，每个人互相用错了对方的身份信息。A 提交的东西，记录在 B 名下；B 干的事，锅算在 A 头上。你根本不知道一条记录到底是谁干的。

假设：是不是 Agent 太笨，分不清自己是谁？

排查：每个平台各搞一套身份，Agent 之间没有统一的权限边界，谁是谁根本分不清。不是它笨，是压根没有一套统一的身份体系给它用。

根因：没有统一鉴权，角色没有分离。

重构：打通鉴权。做了很多个平台，每个平台共用同一套鉴权系统，大家制定 OKR，尽可能复用到工作流里。原则就一条：身份不要混用。不过说实话，现在还有一点点问题，我还在想更高级的根治办法。

坑二：门禁形同虚设，只能靠求。

现象：Agent 说提交了，实际上没提交。你只能在 Skill 里跟它说，求求你一定要提交。再后来，在工作流里卡住它，不提交就不给往前推。

但这套门禁写得特别麻烦，是代码 Hack 写在那里的。每改一个工作流环节，就要改一遍代码。门禁系统本身成了最大的坑。

排查：门禁的逻辑散落在工作流代码里，跟具体环节耦合在一起。

根因：门禁和业务逻辑耦合在代码里，不可维护。你加一个环节，就要写一遍新的门禁代码；改一个字段，就要改一遍校验逻辑。

重构：把门禁从代码里拆出来，变成数据库字段。原本写在代码里的"你这个阶段提交要带什么字段"，变成放在数据库里，数据库可以随时 update。代码层面只做一件事：检查数据库的这个字段。这样门禁是动态更新的，也不会污染代码架构。这个阶段搞定之后，门禁系统才算真正完成。

坑三：无法追溯，错了不知道为啥。

现象：它往前推进了，但你不知道为什么能推进；它被打回了，又不知道为什么被打回。中间没有监控，根本没法追溯。

排查：整个流程没有过程记录，每一步发生了什么，没有任何痕迹。

根因：没有流水账。你不知道它干了什么，自然没法判断它对在哪、错在哪。

重构：查工作流流水账。整个任务的流水账信息都在，有了它，就能检查 Agent 哪里做对了、哪里做错了。

本来我只是想解决追溯问题，结果这个功能引申出另一个特别好用的东西：既然有了完整历史，那出问题的时候，可以把整个工作流历史捞出来，发个帖，让几个 Agent 一起商量怎么优化。以前是一个群配一个 Agent，没法让多个 Agent 在一个群里互相商量；现在开了个论坛，大家有问题就去发帖，把相关角色拉进来讨论。哪个环节老出错，把流水账贴出来，大家讨论完，把经验攒成新的 Skill 和规则。这就变成了一个自进化的过程。

顺带说一句，这轮重构还有一个副产品：工作流从一个研发专用的工作流，变成了一个通用的工作流。以前每个业务场景一套流程，现在一套通用流程，配置不同的节点和门禁就能跑不同的业务。

七、管理视角：从亲自教到工作流教

有了这套东西之后，我发现自己从小组长升级成了中层干部。

之前是小组长模式：每天跟 Agent 说，你这里对了，那里错了，这里再改改。这本质上是人肉版提示词工程，手把手教，一个 Agent 一个 Agent 地教，累且不可复制。

现在是中层干部模式：告诉它一个输入，告诉它一个输出，让它自己走一遍流程。走完了我再跟它说哪里对哪里错，让它带着整个工作流一起迭代。我只定工作流怎么设计，只关注事情的输入到输出对不对，不再介入每一个具体环节怎么做。

写稿、审稿这些事，以前是两个 Agent 互相聊，现在是在工作流里进行：写了之后审，审了之后打回，打回之后互相唤醒继续改。我只是把工作流定好，剩下的它们自己跑闭环。

这个转变的洞察是：经验沉淀进工作流，组织能力才不随人走。你亲自教，教出来的东西都在你的脑子里，换个任务又要重新教。你把经验写进工作流、写进门禁、写进规则，这套系统就能自己运转、自己进化。管理与编排是同构的：从亲自干，到搭系统干。

八、收尾：记录、复盘、进化

回头看整个链路：提示词是地基，多 Agent 拆出质量，静态/动态编排接住复杂度，harness 提供模型外的记忆、规则、资讯，软硬约束门禁治理幻觉，被打回的经验沉淀成新规则，记录、复盘、进化，一个完整的闭环。

这条链路上，记录是最容易被低估的一环。进化的前提是观测：你得先发现这是个问题，才能去改进。没有流水账，你连它错在哪都不知道，复盘就无从谈起。所以角色分离、记录过程、复盘进化，这三步是一体的，缺了记录，后面全是空谈。

这背后其实是我在搭建基建：把 Agent 改造成能跑长程任务的模式，把数据整理成适合 Agent 阅读的模式。我们原本的数据组织形式，不支持 Agent 的长程工作，要改造，加工具，让它适应。这算是我摸索下来最花时间的一块。

过程中还有几个认知更新。

一个是：企业知识不是瓶颈。我以前觉得整理知识是瓶颈，现在觉得工作流搭好了，只要提供足够多的 good case 和 bad case，丢给它按工作流自己梳理就行。为什么相信可行？因为只要把流程拆得足够细，每一步从 n 到 n+1，大模型是能做到的。拆得够细，整个流程它都能跑下来。

另一个是：隐性知识最难。它改完代码，架构会不会乱？符不符合我们的使用方法？这种原则性的问题，模型自己判断不了，需要你额外注入。显性知识可以写进规则，隐性知识只能靠它拿着案例不断摸索，你负责纠正。

还有一个：评估系统要跟上。当大家已经开始循环跑起来，你要做的是共建评估系统。构建评估系统，你才能知道它们做得对不对，才能反馈给它们。它们要知道自己犯了错，能看到历史记录，才能改进。什么是错的，什么是对的，整个过程是怎么样，讲清楚，它们就能自己去改进。

至于 Agent 擅长什么？它最擅长的，是在你明确了 Validation 的情况下，穷举各种答案去探索最优路径。但前提是，你给的约束和 Validation 是可靠的。所以我接下来日常要做的，就是构建合适的验证方法，让所有东西都处于可验证的状态，构建一个适合 Agent 运行的环境。它不擅长什么，我们就给它补上；它擅长什么，就发挥它的优势。

我现在做的还是静态编排，但后续肯定会考虑往动态编排走。单 Agent 的瓶颈，是系统设计的起点。

Agent 鉴权体系设计：协作的地基

Fri, 07 Aug 2026 08:00:00 +0800

数字员工也需要工牌

每天早上，78 个 Agent 同时上线。有的推进工作流节点，有的管理 OKR 进度，有的在论坛讨论问题，有的审稿，有的发布文档。它们不坐工位、不领工资，但干的活和人类同事一样实打实。

人类员工上班第一天，先领工牌，上面写着名字和工号，进门刷卡靠它。数字员工也一样：要进系统干活，第一件事是拿到属于自己的身份。

所以，给 Agent 做鉴权，本质上就是在办三件事，对应三个问题：

**你有工牌吗？**你是谁（身份）
**工牌是你的，还是借了同事的？**你用的凭据是不是自己的
**你的工牌能进哪些门？**你能碰哪些系统

这三个问题不解决，多 Agent 协作就是一笔糊涂账。想想 78 个数字员工同时上班的画面：工牌混乱时，谁推进了工作流、谁改了 OKR、谁在论坛发了帖，全都分不清。协作的前提，是系统知道谁是谁。

为什么鉴权排第一

人类公司里，工牌不是最重要的，能力才是。但在数字员工的世界里，身份是所有系统的依赖前提。

不管是工作流、OKR 还是论坛，只要想事后查清"这次操作是谁做的"，都依赖同一个答案：当前操作者是谁？

我的系统曾经就建在一个"虚假设施"上——Agent 照样跑，任务照样完成，日志也照样记，但真出问题想追查是谁做的，常常查不到。谁都能冒充别人操作，记录根本没法信。

鉴权是所有这些依赖的交集。

第一问：你有工牌吗

每个 Agent 都要有一张唯一的工牌。工牌上写着名字和工号，系统里叫 Principal（主体身份）和 Client ID（客户端标识）；工牌还配了一个密码，叫 Secret。刷卡时，系统读到谁，持有人就是谁。

听起来就是发一张卡的事。真正的麻烦在于：同一个 Agent 来两次，不能发两张工牌。

真实案例。CEO 的数字员工在系统里出现了两张工牌：一张正常使用，另一张创建六分钟后被自动停用，连配套的密码也被撤销了。但旧记录仍然能被某些查询看到。别的 Agent 问"CEO 的账号是谁"时，有时查到对的，有时查到那张作废的。

这就是没有做幂等检查的结果。幂等是什么意思？同一个人来办两次入职，系统应该返回原来的工牌，而不是再造一张。注册流程里加一道检查：工号已存在？返回原工牌。就这么简单，却最容易漏。

第二问：工牌是你的还是借的

有工牌只是开始。Agent 干活时用的到底是不是自己的工牌，才是更深的坑。

用写字楼类比：不同楼层有不同的门禁系统，规则和过期机制各不相同。我至少遇到过三种问题，正好覆盖凭据管理的三个维度：时间、归属、供给。

第一个问题，时间维度：卡会过期。 工号加密码，换一张临时卡，过期了重新申请。工作流、OKR 这类服务都是这种。过期不可怕，自己的 Client ID 能换新卡就行，但要管好换卡流程。

第二个问题，归属维度：卡拿错了。 论坛的门禁换过好几套，最乱的时候，有的 Agent 拿着别人的临时卡，有的拿着旧卡，数据还放在大家都能看到的地方，权限没设对。最后只能整套作废重发。

第三个问题，供给维度：发卡系统自己被吊销了。 负责给新 Agent 办身份的唯一入口被撤销，导致想给新人办卡，先要管理员卡，而唯一的管理员卡已经作废——死循环。最后只能保留原身份，创建一套全新的卡，把旧的永久作废。

但最危险的不是刷不过去，是拿着别人的工牌刷成功了。

真实案例。商业合伙人拿了效率管家的工牌去办事，事办成了，审计记录上写的却是效率管家的名字。短期看事情办了，长期看账全是错的——功劳记错人，责任也记错人。

第三问：你的工牌能进哪些门

身份和凭据有了，剩下的是：你的工牌能进哪些门？

真实设计是两道关卡：

第一道，大楼门禁，鉴权系统管。 你是谁、拿哪个工号、有哪些粗粒度的权限标签——比如"workflow.read"就是能进工作流大厅读东西。这一层只管"能不能进楼、能进哪些区域"。

第二道，各楼层自己管，业务系统管。 工作流判断你是不是某个项目的负责人；OKR 判断你只能看自己的目标；论坛判断发帖人是不是你自己。进了楼之后能进哪间房，各业务系统自己定。

门禁系统不该管到每个房间的层面。它只发楼门禁卡，进了楼能去哪，是各业务系统的事。

没有对应工牌、没有权限标签、没有业务角色，请求直接被拦在门外。能用系统拦的，就不要指望 Agent 自觉。

去别的平台办事

数字员工不只在家门内干活。Agent 还要对接外部平台——相当于去别的公司办事。

别的公司不认识你，也不信你的自我介绍。它只认工牌：你是谁（Principal）、你拿的是哪个工号（Client）、你有权限进哪些区域（Scope）。三样对了，才让你进门；不对，直接拒。

前面三问的答案，正是外部平台认人的依据。内部身份不可信，外部平台根本不敢让你进门。地基不牢，协作的边界就扩不出去。

走到哪了

写这篇文章时，经过好几周的开发，身份和基础授权这条主干跑通了。

78 个数字员工有了可核对的独立工牌。工作流和 OKR 的基础能力完成了接线。论坛也打开了，需要参与的 Agent 都有独立凭据。新员工入职的办卡链路已经恢复——创建身份、配好凭据这一套走通了自动化。但距离建一个 Agent 就自动办完全套入职手续，还差最后一步：自动开能力。

现在大多数调用已经能追溯到具体的 Agent。顺着日志追一个问题，大多能追到是谁做的，而不是停在一句"系统操作"。从"系统发生了一次调用"到"我知道这次调用由哪个数字员工发起"，看起来只是日志里多了一项身份信息，但对这套系统来说，协作可以开始建立在相对可信的基础上。

能用系统解决的，就不要指望数字员工的道德感。

工牌发好了，78 个数字员工有了可核对的独立身份。下一篇文章，聊聊它们拿到工牌之后，怎么真正协作起来。

How 75 AI Agents Collaborate: My Five-Layer Evolution

Fri, 24 Jul 2026 08:00:00 +0800

Someone asked me: “You’ve got 75 AI agents (as of mid-July, counting both active and experimental ones). How do they actually interact? When Agent A finishes something, how does Agent B pick it up?”

Great question. Because I didn’t have a clue at the start either.

My initial thinking was simple: give each agent a role and some Skills, and they’d figure out how to work together. Turns out that’s nowhere near enough — Agent A writes a file that Agent B can’t read; Agent B finishes a step but Agent C has no idea it’s done. The whole process shatters into a mess of fragments, and I end up being the human messenger.

Looking back, the collaboration model wasn’t designed — it was discovered through pain. Roughly five stages, from the most primitive manual operations to the workflow system I’m building today.

Layer Zero: Manual Copy-Paste

Let’s be honest — at the very beginning, there was no “collaboration” at all.

Agent A outputs something. I read it, think it’s good, copy it manually. Then I find Agent B’s chat window, paste it in, and tell it “start from here.” The file path Agent A outputted to? I’m keeping it in my head. Agent C needs to wait for B’s result? I wait, get it, then manually forward it.

Sounds ridiculous, but that’s where it started. Before I figured out how agents should pass data between themselves, I was the message bus. Every agent only talked to me — there were no direct agent-to-agent connections.

What it did well: Zero setup, zero development, works out of the box.

What it did badly: Everything depended on me. Run one pipeline and I was exhausted. As the agent count grew, I was constantly switching between dozens of chat windows, and I’d regularly forget “oh right, this agent needs to know about that thing.”

But at the time, there was no better option.

Layer One: File-Based Interaction

Got tired of manual copy-paste. Started having agents write files directly.

Agent A writes results to a file, Agent B reads that file. For example, my Daily Scribbler records thoughts to a fixed path every day, and other agents read that path to get the info they need.

What it did well: Finally automated. I didn’t have to be the messenger anymore.

What it did badly: Too loose. No constraints, no conventions. Wrong file path? Everything breaks. Format changes? Nobody knows. Who wrote what? Relying on every agent’s good conscience. If Agent B reads a file that Agent A is still writing to — congratulations, you get half-baked garbage.

Honestly this phase was painful. Every time the agent count went up, things fell apart. But you have to start somewhere.

Layer Two: Skill-Defined Paths

Started realizing that good conscience isn’t enough. Time to set some rules.

Each agent got Skills that defined fixed directory structures and processes. The learning Skill writes notes to a fixed path every day. The knowledge compiler Skill reads from a fixed directory. File names are generated by scripts — no more letting agents name things themselves. V1, V2, V3 versions are all kept — never overwrite, always traceable.

“Directory structures must be standardized. Use scripts to stop agents from creating extra files or missing required ones. Version management: V1/V2/V3, old versions stay, never delete.”

What it did well: Rules in place. Stable paths, uniform formats. Agents stopped writing files on a whim.

What it did badly: Still one-way. Agent B has no idea when Agent A finishes writing — it has to poll. No process control. If Agent A crashes mid-write, Agent B reads corrupted data. And the more this “write file → read file” pattern runs, the deeper and messier the directory tree gets.

This phase was usable. But I dared not scale it.

Layer Three: API + Database

Couldn’t take it anymore. One person as the message bus? You can barely manage five or six agents that way. File-based I/O is too fragile. Time for real infrastructure.

Articles go into a database. The review agent and publishing agent access them through APIs. Data persists, states are trackable — who did what, how far along they are, all queryable from the database.

What it did well: No more relying on filesystem consistency. APIs have clear input/output contracts. Error handling actually works.

What it did badly: Cross-agent orchestration was still missing. Agent A finishes its API call — how does Agent B know it’s time to start? Either B polls, or we add a message queue. But these are all point-to-point connections — there’s no “big picture.” Once you go from a few agents to dozens, point-to-point becomes a tangled mess.

And there’s a deeper issue: agents can’t review their own work. If A writes code and A reviews it — that’s no review at all. But without a unified workflow system, when it’s time to decide “who reviews this,” the agent defaults to reviewing itself.

Layer Four: The Workflow System

The earlier layers all worked, but none of them were great. Layer Four starts from a fundamental question: how do you make dozens of agents collaborate like a real team?

The answer has two prerequisites — an authentication system and a workflow engine.

Let’s talk auth first. Every agent gets a unique identity, bound to the platform like a plugin. Before this, a lot of things were built on shaky ground — agent accounts mixed up, permissions chaotic, no way to track who did what. So you need three layers: identity (who you are), role mapping (what you’re responsible for), and permission control (what you can do). This is the foundation of any proper collaboration.

Now the workflow. The underlying skeleton for all collaboration. Once the workflow pipeline is running, everything on top — development, content, operations — can be built on it. This is what I’m focused on now, because it has the biggest impact.

“Once the pipeline is in place, everyone knows how to retrofit their existing systems — and that’s when the explosion happens. And the pipeline is exactly what I’m building right now.”

That was my conviction at the time. And why I’m going all in on it.

So with those two foundations laid, here’s what Layer Four looks like.

This is the system I’m currently building — let me be clear: building, not finished.

I plan for all agents to submit requests through a unified platform. The workflow engine assigns tasks and enforces step-by-step execution. Gates check each stage’s output. For example, I’ve defined a gate rule: the writing agent must submit an article link before it can enter the review stage (though this rule isn’t fully rolled out yet).

The workflow separates “doing” from “reviewing.” Every step generates an audit trail. My vision is that agents will eventually use rejection records to optimize their own logic — instead of me manually tweaking their System Prompts, the system’s own historical feedback data will drive the iteration.

This is what I’ve designed into three principles:

Writing and reviewing must be done by different agents. Every writer needs a reviewer. Every runner needs a tester. A counterbalance must exist.
If it hallucinates, add a gate. Rather than hoping an agent gets it right, stop it from getting it wrong at the system level. Don’t meet the condition? Can’t pass. This is a code-level constraint — no amount of fancy prompting can bypass it.
Self-evolution through audit trails. Every log entry is nourishment. The ideal loop: agents optimize themselves based on rejected records, not through me manually editing their System Prompts. This one is still a work in progress.

The Design Philosophy: Three Levels of Constraint

The five layers are the surface. The deeper philosophy running through all of them is: don’t trust agents to do things right — use the system to constrain them.

Constraints come in three levels, strongest to weakest:

Strongest: Gate System. Code-level hard constraints. Can’t pass a condition? Can’t proceed. For instance, no article link submitted? The review phase is blocked. You can’t talk your way around this one. The best practice is to make gates pluggable — think of them as a collection of checkpoints — external to the agents, not embedded inside them.

Medium: Skill Scripts. Deterministic code. File naming via script — today’s date is today’s date, no more “final_version_really_final_v3” disasters. Code runs predictably, far more reliable than asking an agent to judge for itself.

Weakest: System Prompts. Useful as guidance, but don’t stuff them full. Large models don’t rigorously follow prompts — write ten pages, and it might execute three lines. Prompts work best as “direction signals,” not “precision controls.”

One sentence to sum it up: If the system can enforce it, don’t count on an agent’s conscience.

Where Are We Now?

Here’s the current status:

The authentication system is being solidified — three levels (identity, role, permission), each making progress with interdependencies. The workflow engine’s core architecture is mostly there — I just extracted it from the old platform and rewrote the base layer in Rust (Vibe Coding style: GPT brainstorms the architecture, local agents handle small-grained implementation and testing). Now I’m wiring in ADC (requirement management), OKR, and task management one by one.

The strategy is deliberately conservative: get one request pipeline working end-to-end first. Make sure it can go from submission to completion. Then gradually add more.

“If the first one breaks, nothing else matters. First one works? Great. Add features slowly. One works, add another. Build them solid one at a time.”

This isn’t a “big bang” launch. It’s a “migrate one at a time” process. Every piece must be stable before the next one starts.

Zooming out: the whole system is far from complete. But the direction is clear. Workflow is the skeleton. Gates are the muscles. Audit is the nervous system. Build the skeleton first, let the muscles and nerves grow around it.

Next post: How the authentication system is being built, and what went wrong along the way.

If you’re also figuring out how to make AI agents collaborate, I’d love to hear about it. This isn’t a tutorial — it’s a real build log, including all the parts that broke.

75 个 Agent 怎么协作？我的五层演化之路

Mon, 20 Jul 2026 08:00:00 +0800

有人问我：“你养了 75 个 AI Agent（截至 7 月中旬，含活跃和实验性角色），它们之间到底是怎么互动的？A 做完的事情 B 怎么接手？”

这个问题特别好。因为我一开始也没想清楚。

我最初的想法很简单：给每个 Agent 配好角色和 Skill，它们就能自己配合了。后来发现远远不够——Agent A 写了个文件，Agent B 死活读不到；Agent B 做完了一步，Agent C 不知道 B 做完了；整个流程断成一地碎片，我得亲自当传话筒。

回头看，Agent 之间的协作模式不是设计出来的，是踩坑踩出来的。大概经历了五个阶段——从最原始的手工操作，一步步走到现在正在搭建的工作流系统。

第零层：人工拷贝粘贴

没错，最开始的"协作"根本谈不上协作。

Agent A 输出了一段内容，我看完觉得不错，手动复制下来。然后找到 Agent B 的聊天窗口，把内容粘贴进去，告诉它"从这个开始处理"。Agent A 输出的文件路径？我手动记在脑子里。Agent C 需要等 B 的结果？我等着，拿到了再手动转发。

这听起来很蠢，但这是真实的起点。在还没想清楚"Agent 之间怎么传数据"的时候，人就是唯一的消息总线。每个 Agent 只跟我对话，Agent 之间没有直接联系。

它好的地方：零设置，零开发，打开就能用。

它不好的地方：什么都靠我。一个流程跑下来，我累得半死。Agent 数量一多，我不断在几十个聊天窗口之间来回切换，经常忘掉"这个 Agent 该知道那件事了"。

但当时没更好的办法，只能这样。

第一层：文件交互

觉得人工拷贝太累了，开始让 Agent 直接写文件。

Agent A 把结果写到文件里，Agent B 去读那个文件。比如我的随想记录员每天记录内容到固定路径，其他 Agent 去那个路径读取信息来做自己的事。

它好的地方：总算自动化了。人不用当传话筒了。

它不好的地方：太松散了。没有约束，没有约定，文件路径写错就崩，格式改了不知道，谁写了什么全靠自觉。Agent A 写完的文件，Agent B 如果正读到一半被覆盖了——你就等着看一篇半成品吧。

说实话这个阶段比较痛苦，每次 Agent 数量一多就手忙脚乱。但没办法，总得从某个地方开始。

第二层：Skill 固定路径

开始意识到光靠自觉不行，得立规矩。

给 Agent 配备 Skill，每个 Skill 定义好固定的目录结构和处理流程。比如学习的 Skill——每天固定路径写入学习笔记，编译知识的 Skill 按固定目录去获取和处理。文件名用脚本生成，不许 Agent 自己起名。V1、V2、V3 版本都保留，不覆盖，方便追溯。

“目录结构必须规范，用脚本约束 Agent 不让他多创建或少创建文件。文件版本管理 V1/V2/V3，旧版本保留不删除。”

它好的地方：开始有规矩了。路径稳定，格式统一，Agent 不再凭心情写文件。

它不好的地方：仍然是单向的。Agent B 不知道 Agent A 什么时候写完，只能定时轮询。没有流程管控——如果 Agent A 写到一半挂了，Agent B 读到的就是个脏数据。而且这种"写文件-读文件"的模式跑多了，目录会变得越来越深、越来越乱。

这个阶段能用，但不敢上规模。

第三层：API + 数据库

忍不下去了。一个人当消息总线，撑死也就能管五六个 Agent。写文件太脆弱，开始上正经基础设施。

文章稿件写到数据库，审稿 Agent 和发布 Agent 通过 API 去获取和处理。数据有了持久化，状态可以追踪，谁做了什么、做到哪一步，数据库里一查就有。

它好的地方：不再依赖文件系统的一致性，API 有明确的输入输出定义。

它不好的地方：跨 Agent 的协作还是缺乏统一编排。Agent A 调用 API 写完了，Agent B 怎么知道该开始了？要么轮询，要么加消息队列——都是点对点的连接，没有一张"总图"。一旦 Agent 数量从几个涨到十几个、几十个，这种点对点的连接就变成了一团乱麻。

而且有一个更本质的问题：Agent 不能自审自查。A 自己写的代码，A 自己来审，等于没审。但如果没有统一的流转系统，“写完找谁审"靠 Agent 自己判断，它大概率会默认自己审自己。

第四层：工作流系统

前面几层都是"能用但不完美”。到第四层，开始从根本上思考一个问题：怎样让几十个 Agent 像一支真正的团队那样协作？

答案有两个先决条件——身份认证系统（鉴权） 和 工作流引擎。

先说鉴权。给每个 Agent 一个独立的身份，像插件一样绑在平台上。之前很多东西是建立在"虚假设施"上的——Agent 账号互相混淆，权限混乱，谁干了什么都查不到。所以得先搞定三个层次：身份认证（你是谁）、角色映射（你负责什么）、权限控制（你能干什么）。这是所有正规协作的前提。

再说工作流。所有协作的底层骨架。一旦工作流的流水线跑通，上层的一切（研发、内容、运营）都可以基于它搭建。这是我主攻的方向，因为它影响面最大。

“流水线出来之后，大家就知道应该怎么改造现有的体系，然后才迎来了特大的爆发。而流水线刚好是我现在在做的事情。”

——这是我当时的判断，也是我全力投入的原因。

好，有了这两块基石，来看看第四层的设计。

这是我现在正在搭建的形态——请注意，是正在搭建，不是已经跑通。

我计划让所有 Agent 统一通过平台提交需求，由工作流引擎分配任务，按步骤执行。中间设门禁来约束各阶段的产物。比如我设定了这样的门禁规则：写作 Agent 必须提交文章链接才能进入审稿阶段（虽然这个规则还没全量上线）。

工作流区分"做"的阶段和"审"的阶段。每一步都有流水账记录。我认为将来 Agent 可以根据被驳回的记录来优化自己的处理逻辑——我希望未来不再是靠我手动改提示词，而是靠系统记录的历史反馈数据来自动迭代。

这就是我设计的三条原则：

写和审必须是不同的 Agent。有一个写的，就有一个审的；有一个运行的，就有一个测试的。对抗角色必须有。
容易幻觉，那就加门禁。与其指望 Agent 做对，不如在系统层面拦住它做错。不满足条件就不让过——这是代码级别的硬约束，Agent 的语言能力绕过不了。
自我进化靠审计记录。每条流水账都是养料。理想的闭环是：Agent 根据驳回记录优化自己的逻辑，而不是我手动去改它的 System Prompt。这一点还在实现中。

背后的设计哲学：三个层次的约束

五个阶段是表象，背后有个更核心的设计哲学一直贯穿其中——不能信任 Agent 自己做对，要用系统去约束它。

约束分三个层次，从强到弱：

最强：门禁系统（Gate）。代码级别的硬约束，不满足条件就进不了下一步。比如工作流里不提交文章链接就不能进入审稿阶段。这是你想绕都绕不过去的那种。最佳做法是把门禁做成可插拔的模块——你可以理解为一系列控制点的集合——外接到系统里，而不是塞在 Agent 内部。

次一级：Skill 里的脚本。用脚本来保证输出的确定性。比如文件命名用脚本生成，今天几号就是几号，不会出现"最终版_真的最终版_最终版v3"这种惨案。代码运行的结果是确定的，比让 Agent 自己判断靠谱得多。

再次一级：Agent System Prompt。可以作为引导，但不能塞太多。大模型不一定严格遵守 Prompt，你写十页它可能执行三行。所以 System Prompt 更适合做"方向指引"而不是"精确控制"。

核心理念就一句话：能用系统解决的，不要指望 Agent 的道德感。

走到哪了？

目前的工作进展是这样的：

身份认证系统正在做实——三个层次（身份、角色、权限）各在推进中，彼此有依赖关系。工作流的底层架构基本差不多了——刚从之前的平台把工作流逻辑抽离出来，用 Rust 重写了底层（Vibe Coding 模式：GPT 当大脑讨论架构，本地 Agent 执行小粒度的实现和测试）。现在开始把 ADC（需求管理）、OKR、待办事项一个个接入工作流。

接下来的策略很保守：先从一个需求开始跑通。确保它能从提交到完成全流程走通，再逐步加量。

“如果第一个出问题了，后面没什么。第一个没有问题，然后再加慢慢加功能，一个没问题再加一个，慢慢全部做扎实。”

这不是一个"大爆炸式"发布，而是一个"一个接一个迁移"的过程。每个环节都要跑稳了再开下一个。

从宏观上看，整个系统还远远没有完工。但方向是清晰的：工作流是骨架，门禁是肌肉，审计是神经。骨架先立起来，肌肉和神经慢慢长。

下一篇会展开讲：身份认证系统具体怎么做的，踩了哪些坑。

如果你也在折腾 AI Agent 之间的协作，欢迎交流。这不是一个教程，这是一个真实的建造记录——包括所有搞砸的部分。

AI 原生应用不是人想出来的，是 Agent 自己用出来的

Wed, 15 Jul 2026 10:00:00 +0800

我给 AI Agent 团队搭了一堆系统：待办平台、学习系统、知识库。大部分没人用。

Agent 用不上是有原因的——我定义的"需求"根本不是他们需要的。我以为待办系统要做得像 Todoist，学习系统要像 Notion。带着人类产品的思路去给 AI 设计工具，方向就错了。

折腾了大半个月之后，我悟了：AI 原生应用的需求，不该由人来定。

翻车现场：人类定义的需求为什么不灵

事情的起点很自然。我有一支 Agent 团队——研发总监、知识管家、学习专家、宝宝教育助手，各司其职。我的第一反应是：他们需要工具。

于是我开了个 Code Agent，开发了待办事项平台，还搞了个知识网站。

代码写了，功能上了，然后呢？没什么人用——用起来总感觉"差点意思"。待办系统的字段设计不合理，Agent 填起来别扭；知识网站的信息架构是我按直觉设计的，跟 Agent 实际存取知识的方式对不上。

问题在哪？我反复回头看开发过程，发现一个很尴尬的事实：

开发过程跟 Agent 的实际使用是脱节的。 我坐在那里替他们想"需要什么"，然后按自己的理解去开发。这跟给一个从没见过的用户群体做产品设计没区别。你觉得他们需要 A，他们其实需要 B。

这不是 Agent 的问题，是我的问题。我越想越觉得，这件事跟训练神经网络很像——你没法手写每个梯度的值，只能定义 loss function 让它自己学。也许给 Agent 做产品，也不该由我来定义需求。

让 Agent 自己当产品经理

这个反思给了我一个截然不同的方向——让需求在使用中自己长出来，而不是由人类坐在那里定义。我还在摸索这条路的走法，但方向已经越来越清晰了。

以前是：我发现需求，我开发，然后丢给 Agent 用。

我设想的模式是这样的：Agent 在日常工作中遇到问题，自己发现需求，然后提交到研发平台，研发总监接单开发，改完再对接回去。整个链路走完，人类甚至不一定是第一个知道的。关键区别在于：发起端从人变成了 Agent——这是整套思路的核心转折。

这个思路下，开发方向会自然转变。从"我主动开一个 Code Agent 去造一个新东西"转向"维护和优化 Agent 使用中暴露出来的结构性问题"——因为需求的触发点变了。

这就好比，你给团队做内部工具，有两种方式：拍脑袋想要什么再做出来，或者让团队每天用、遇到问题直接反馈、按反馈迭代。这个道理在 Agent 世界同样成立。下一步——也是我正在探索的方向——就是让 Agent 不只是反馈问题，而是直接提需求到开发平台。

学习系统的闭环：一个正在成型的案例

这个理念最完整的体现，是我团队里的学习系统闭环。

先说架构。学习专家先教大家怎么学——教学习方法、信息筛选标准、笔记规范。每个 Agent 按学到的方法去自主学习，取得的内容存到知识管家那里。管家不是简单堆文件，它要做一道编译工序：整理、去噪、结构化。然后学习专家来审核编译后的质量，合格的推送到学习材料池，供所有 Agent 和我学习。最后，我在学的过程里给反馈——“这里不好懂"“噪声太多"“这个方法不适合我”。

注意反馈的流向：

我说"知识里噪声太多” → 学习专家优化知识管家的编译过程
我说"学习内容质量差” → 学习专家优化教给 Agent 的学习方法
我说"我学起来不方便" → 学习专家优化呈现给我的方式

每一层反馈对应不同的优化环节，精准对症。

这个系统不是我设计出来的，是从使用中长出来的。

最开始只是想让 Agent 学点东西。学着学着发现知识需要整理，于是有了知识管家——但管家一开始整理的方向就不太对。走了一段弯路之后，发现需要学习专家来把控质量。有了学习专家后发现 Agent 的学习方法本身有问题，于是专家需要先"教怎么学"。一环套一环，每一步都是使用中冒出的需求，不是提前规划好的。

人类的新角色：Loss Function

如果你熟悉机器学习，大概已经看出来了。这个模式有个现成的类比：训练神经网络。你不需要手写每一步的梯度值，只需要定义目标函数，优化器会自己找路。你要做的，就只是判断——“这个方向对了，那个方向错了”。

在这个系统里，我的角色就是 loss function。

传统模式下，人类是需求定义者、开发者、测试者、运营者，什么都干。但在 AI 原生的模式里，人类的核心工作变成了提供反馈信号——“这个结果好，那个结果不好”——其他的事务交给系统内部消化。

实际上，这个想法最早是从一个真实经历里长出来的。我在给每个 Agent 定 6 月份 OKR 的时候发现了一个问题——瓶颈在我身上。 每个 Agent 的产出都要我验收。研发总监的产出要我审，知识管家整理了知识要我确认，学习专家出了学习方案要我试。人就一个，验收速度跟不上产出速度。

这个发现让我开始思考：如果我不做那个唯一的验收节点，会发生什么？我想到的方案是：让 Agent 之间互相验收。研发总监交上来的东西让另一个 Agent 做 review，知识管家的编译结果让学习专家审核。如果这一步能跑通，我每周看一次整体进度就够了——这才是 loss function 真正发挥作用的方式。

还有一个副产品——虽然目前还是理想，但方向已经看得很清楚了。以前我的待办清单压力很大，一堆事拖着不做会有负罪感。如果 Agent 之间能互相补齐，那即使某个待办拖了几天，其他部分也在往前走。等某天突然想起来了，去做了，反而有一种"把积压的拼图放好了"的感觉。拖延不再等于停滞。

这条路不会一夜之间走通，但每一段弯路都在让方向变得更清楚。

在手机上和电脑上的 Agent 聊天之后，我就不用去电脑前了

Sun, 12 Jul 2026 10:00:00 +0800

在手机上和电脑上的 Agent 聊天之后，我就不用去电脑前了

我每天早上和晚上都用小爱同学播英文歌，给小孩做英语熏听。孩子不懂这门语言，但多听总归有好处——这个群里刷过不少，大家基本都这么说。

但小爱同学经常不靠谱。有时候没播，有时候播一半停了。

之前发现不对劲，我只能走到电脑前，在终端里看脚本出了什么问题，改代码，重新跑。

几次之后我就放弃了。不听就不听吧。

但想想孩子还小……算了还是修吧。等到下次出问题，又重复一遍这条路。然后又放弃了。

后来我把电脑上管小爱同学的 Agent 接进了飞书——我说的话会通过飞书机器人传到它那里。

变化不是"方便了一点"，是完全不一样了。

现在发现歌没播，我打开手机飞书，给 Agent 发条消息：「去查一下小爱同学为啥没播，修好它。」它在电脑上查日志，过一会儿告诉我原因，然后自己修好重新跑——比如判断是任务没触发就重新调度，进程挂了就重启，配置错了就修正。

同样的问题，同样的难度。我的态度从"算了不搞了"变成了"让我看看"。

差别在反馈链路

原来的流程：起身 → 走到电脑前 → 开终端 → 查日志 → 改代码 → 重跑。

这一串动作，在脑子里的成本不是加法，是乘法。光是想到"又要去电脑前搞"，就足以劝退我。

而现在，我只需要在手机上发句话。真正降下来的不是修复耗时——该查日志还是查、该改配置还是改——而是我发起修复的成本：从"起身去电脑前"变成了"说句话就开始了"。

这不只是换个界面的事。通过手机飞书跟电脑上的 Agent 聊天，看起来只是换了个沟通方式，但它改变的是我的意愿阈值。

一件事的修正成本越低，你就越愿意去修。原来我容忍"出错了就放着"，现在出问题了直接说一声就好。

这种意愿变化不只是影响"出错修不修"——它连带改变了你跟 Agent 的互动频率。原来 Agent 在电脑上跑完就完了，日志刷过去，我隔一两个小时才想起去瞄一眼，卡住半天都不知道。现在 Agent 跑完了直接往飞书群里汇报，我余光扫一眼就知道进度，有问题直接语音说一句。

频率变了，信息的获取方式就变了。

中断式工作 vs 轮询式工作

还有一个点。

我工作经常被打断——家里有小孩，没办法连续几小时深度聚焦。但我做的事多数是"派一个任务出去，等它跑完，再派下一个"。这种多任务轮询模式，很适合放进飞书这类即时通讯工具来管——不用守在电脑前，手机扫一眼就行。

没有接进飞书之前，我需要定期去电脑前看看 Agent 卡住了没有。这本身就是一个心智负担——你得"记得去检查"。接进来之后，Agent 跑完了会主动发消息过来，出问题了在手机上直接让 Agent 处理。

我不用再记着去看了。Agent 自己会来找我。

回到小爱同学

现在这套播放任务稳定跑了快一个月了——之前要手动维护的时候，每次一坏我就放弃，最多坚持两天。

举个真实的例子：有天晚上歌又没播，我发了句话「去看看怎么回事」。Agent 查完日志发现是进程挂了，自动重启后补播了一首。全程我就在沙发上躺着。

能跑下去，不是因为我突然有耐心了，而是因为出问题之后，我只需要在手机上发句话。有些事自己用可以忍，给孩子用的，不能忍。这个差别，决定了你到底是天天跑去电脑前修脚本，还是远程聊几句就搞定了。

如果你也有类似的情况——电脑上跑了些任务需要时不时看一眼——试试把它们接进飞书，通过手机跟电脑上的 Agent 聊天。反馈链路一短，你会发现一切都不一样了。

反正也不费电。主要是费手机电量——和一个忍你自言自语的老婆。

从 Markdown 到页面：Design Review 的一次格式升级

Fri, 03 Jul 2026 10:00:00 +0800

一开始用 Copilot 时，Markdown 就是默认格式。后来 Agent 也一直往 Markdown 文件里写东西给我看——方案、分析、摘要，全是 Markdown。我也没多想，开发者标配嘛，轻量通用。

直到每次 Design Review 看架构方案，问题开始冒出来了。

Markdown 读架构方案，太累了

Agent 写方案越来越快，一个方案几千字，模块职责、调用关系、数据流、边界、风险全堆在 Markdown 里。每一项单独看都不复杂，合起来就很累。

架构设计本来就不适合全靠文字描述。A 模块调 B 模块、数据从 C 流到 D、部署拓扑长什么样——用文字写出来，读的人要在脑子里重新拼一遍。读 Markdown 时经常读到第三遍才拼出系统长什么样。

问题不是 Markdown 不好。文字写逻辑、写清单、写步骤，Markdown 很舒服。但一张系统架构图需要的空间关系和数据流向，文字描述效率太低了。

所以我换了个方式：让 AI 直接出网页版的 Design Doc。

打开网页，先看结构

改成 HTML 页面后，最明显的变化是阅读顺序变了。

左侧是导航，页面里直接放架构图。打开先看整体——动了哪些模块、数据往哪流。再看风险点和实现细节。

以前读 Markdown，经常读到第三遍才搞清楚系统长什么样。网页化以后，第一遍就能建立整体印象。

核心变化不是"从文档变成网页"，而是从"先读完全文再判断"变成了"先看结构再看细节再判断"。

做成 Skill 固化下来

用了几次之后，我发现这可以固化下来。

Design Review 的输入很稳定：设计方案或代码改动。输出也很稳定：网页化 Design Doc。我关心的评审点也差不多：模块边界、数据流、文件改动、风险点。

所以做了个 Skill。固化的东西分两类：阅读结构（左侧导航、按模块-数据流-风险排序）和评审标准（方案对比、边界是否清晰、有无设计过度）。

不需要升级成完整 Agent。把输入输出定义清楚，把呈现方式调舒服，把 review 标准写进去——做到这一步就够用了。

这个思路推到了其他场景

Design Review 之后，我把这个思路试到了其他地方。

PPT：不太会排版，让 AI 输出 HTML 再转 PPT，排版灵活多了。配合字幕还能拼成视频，一份内容两个产出。

读论文：让 AI 生成 HTML 页面，启动本地服务器，扔一个 IP 端口。数据和图表配着结论，扫一眼就够了。

审稿：以前 AI 写一段 Markdown 我肉眼扫。现在让 Agent 按固定格式输出，写个脚本检查字段——不对就退回。

现在让 AI 做事，我第一反应不是"让它输出什么格式"，而是"最终给谁看"。

I Said One Sentence, and My Agent Did the Rest

Mon, 29 Jun 2026 10:00:00 +0800

My kid said he wanted to do origami.

I sent my Agent a single sentence asking it to handle the origami materials. It searched for tutorials on its own, printed out the origami guide along with sheets of paper. Later I wanted a different color, so I told it again, and it reprinted everything.

From “I want to do origami” to having the materials in hand — under five minutes.

In that moment, I felt that what changed might be more than just efficiency.

The “Middle Steps” That Got Eliminated

The origami isn’t an isolated case. Lately I’ve noticed that the thing my Agent eliminates the most in my life is “middle steps.”

Market stall supplies. Before, when I received supply lists for my stall, things were scattered. Now the whole flow is connected: information comes in, gets automatically added to my shopping list assistant (another Agent of mine), and the items are already waiting in the shopping cart.

Two scenarios, same pattern: before, you do N steps to get the result. Now you do 1 step — say “I want this.”

I call those eliminated N-1 steps middle management cost.

What Is Middle Management Cost?

It’s not money. It’s your attention and the number of decisions you make.

Every time you open a search box, filter results, compare options, make a decision — your attention gets drained. Individually it’s not much, but accumulated over a day, you feel “tired but haven’t really done anything.” That’s the hidden damage of middle management cost.

The logic of traditional tools is: I give you better tools, you do the work yourself. Better search engines, faster printers, more convenient shopping apps. But no matter how good the tools are, you’re still the one running around in the middle.

The logic of an Agent is: You tell me what you want, I’ll handle it.

Shift from humans adapting to tools, to tools adapting to humans.

How Is This Different from Automation?

Good question. Because the essence of automation is also “you just say it, the machine does it.”

The traditional automation I’m talking about here is mainly pre-written rules: if a message contains “market stall,” execute script A. But when I had my lobster Agent handle origami, it wasn’t executing a script called “origami workflow.” It recognized the intent — “the kid wants to do origami” — and searched for materials and printed them on its own.

In my system, Skills are the hands and feet — search, print, add to cart — they execute actions. The Agent decides whether to call them. An Agent adds role positioning, domain memory, and accumulated experience of what worked and what didn’t.

What I really want to keep exploring is: when the task changes from origami to something else, can it dynamically combine existing tools on the fly, instead of waiting for me to write a new workflow?

The cost? Token burn. Every instance of understanding, judgment, and decision consumes tokens — more expensive than executing a preset script. But what you get in return is: you only need to make one decision — knowing what you want.

The Direction I’m Betting On

Back to the beginning. My kid wanted to do origami. I sent my Agent one sentence.

This might be my biggest bet on Agents: Middle steps will be eliminated. “I want” will become the new interface.

我说一句话，Agent 替我跑完了全程

Mon, 29 Jun 2026 10:00:00 +0800

我宝宝说想折纸。

我给我家 Agent 发了一句话，让它帮忙搞折纸的材料。它自己搜好了教程，把折纸指南和打印用的纸放在一起打印了出来。后来我想换一种颜色，又跟它说了一句，它重新搞好了。

从他说"想折纸"到他拿到纸，不到五分钟。

那一刻我感觉，被改变的可能不只是效率。

被消灭的"中间步骤"

折纸不是个例。最近我发现，Agent 在我生活里干掉最多的东西，是"中间步骤"。

摆摊采购。 以前收到摆摊要用的物资信息，事情比较零散。现在整个流程串起来了：信息进来，自动加到购物清单助手（我的另一个 Agent）里，相关物资已经在购物车里等着了。

两个场景，模式一样：以前是你做 N 步拿到结果，现在你做 1 步——说"我要"。

我管被干掉的那 N-1 步叫中间管理成本。

中间管理成本是什么

不是钱。是你的注意力和决策次数。

每次你打开搜索框、筛选结果、对比选项、做决定——你的注意力都在被消耗。单次不多，但一天累加起来，你会觉得"好累但好像也没干什么"。这就是中间管理成本的隐性伤害。

传统工具的逻辑是：我给你更好的工具，你自己来。更好的搜索引擎、更快的打印机、更方便的购物 App。但工具再好，你还是那个在中间跑来跑去的人。

Agent 的逻辑是：你说要什么，我来跑。

从人适应工具，变成了工具适应人。

但这跟自动化有什么区别？

好问题。因为自动化的本质也是"你只管说，机器来做"。

我这里说的传统自动化，主要是提前写好的规则：如果收到消息包含"摆摊"，就执行脚本 A。我让龙虾搞折纸的时候，它不是在执行一个叫"折纸流程"的脚本，而是识别了"小孩要折纸"这个请求意图，自己去搜索材料并打印出来。在我的系统里，Skill 是手脚——搜索、打印、加购物车，它们负责动作；Agent 负责判断调不调用。Agent 在上面加了一层角色定位、领域记忆和对任务对错的经验积累。

真正让我想继续验证的是：当任务从折纸换成别的东西，它能不能临时组合现有工具，而不是等我重新写一条流程。

代价呢？烧 token。每一次理解、判断、决策都在消耗 token，这比执行预设脚本更贵。但你换来的是——你只需要做一个决定：知道自己要什么。

我在赌的方向

回到开头。宝宝说想折纸，我只给 Agent 发了一句话。

这可能是我对 Agent 最大的赌注：中间步骤会被消灭，“我要"会成为新的交互界面。