同时启动四个Agent工具、并行跑几十个对话框——这套让我又依赖又头疼的工作流，是如何长成的？本文将分享我的实践与优化心得。
核心内容：
1. AI原生工作流的演变与多Agent工具初体验
2. 自研记忆同步工具KeyMemory及其“梦境”功能
3. Loop工程实践与多Agent协作的挑战与解决方案

数字生命1001 AI EXPLAINER

我的 AI原生工作流实践记录

同时启动四个Agent工具、并行跑几十个对话框——这套让我又依赖又头疼的工作流，是怎么一步步长出来的？

好久没更新了，想聊聊我最近在折腾的事。

现在每次打开电脑，我都得同时启动四个不同的Agent工具，多的时候每个工具还开着三五个对话框并行跑任务。这套让我又依赖又头疼的工作流，是怎么一步步长出来的？我从头说起。

大概从去年十二月开始，我开始使用OpenClaw。今年三月它在国内火起来之后，新的Agent工具层出不穷，比如Pi Agent、Hermes、OpenHuman等等。身边很多朋友开始问我该怎么选、怎么用到工作里。加上平时上课的需要，我也得花更多时间逐一试用，了解它们各自的优劣势和适用场景。

国内外企业涌入Agent赛道的速度更快。腾讯WorkBuddy、阿里悟空、字节Trae Work、OpenAI Codex，这些名字在最近半年的朋友圈里反复出现。为了了解它们，我也开始一个个试用，并尝试融入我的工作流。日常办公我习惯用Hermes，写代码我喜欢Codex，WorkBuddy经过几次快速迭代后，最近也进了我的常用列表。

第一个问题：记忆同步

同时使用多个Agent工具，我遇到的第一个问题就是记忆同步。

每个Agent留下的记忆只能在其自身框架内读取，上下文是割裂的。你在这边跟它聊了一个小时的项目背景，切换到另一个工具，它完全不知道你刚才做了什么、你的偏好是什么。我试过好几个开源的Agent记忆框架，发现处理这个问题时总是各有各的不足。

我给自己写了一个记忆工具，叫KeyMemory。现在我所有使用的工具，最终都会往这个工具里回写一份记忆。Agent在工作过程中，也会到这个记忆库里去读取我的习惯偏好、过往工作上下文等等。

记忆多了以后，我给它加了一个"梦境"功能。给它配置了一个大模型的API Key后，它会每晚定时分析新增记忆与旧记忆的关联，看看是否有进化、补强、桥接或迭代等关系，寻找各个观点、想法、做法之间的联系，并把它们串联起来，包括去重合并。如果有些记忆只是同一件事的不同说法，细节略有差异，它就会被重新合并，以确保整个记忆库的健康。

但光把记忆一条条堆进去还不够。虽然大模型能定期推理、帮它们建立关联，实际命中效果还是不理想。于是我又做了一个以项目为核心的整理功能，当系统发现一批碎片化记忆其实指向同一个项目时，就自动建个文件夹把它们收进去。底层支持多级文件夹，可以一层层往上套。

Loop工程与多Agent协作

最近，LOOP工程非常热门。我第一次认识到Loop的价值，是在使用Codex的时候。Codex有一个目标模式，你只需要给它一个明确的目标，之后就不用再干预了，模型会一直运行，直到达成目标为止。我跑过最长的一个项目持续了三十个小时，消耗了大约九亿多Token。

但最终的效果一言难尽。

这次经历让我第一次真正理解了Loop工程的价值。

此前为了帮助朋友在生产环境中落地，我已经开始搭建一个多Agent协作框架。

我自己其实也在使用这种多Agent协作框架。最初，我设置了一个默认的秘书Agent，它下面配置了我日常工作中经常用到的各种专用Agent，比如负责研究、计划、写代码、写文章、审阅合同或提供法律建议的。因为目前市场上的模型各有专长，GLM 5.2擅长编程，MiniMax和MIMO在Agent应用上更经济。在写作方面，除了原有的Claude Opus 4.6能带来更好的文字质感，现在国产的月之暗面Kimi 2.6在中文写作上的效果也很能打。

所以，我的做法不是购买一个Token套餐来处理所有工作，而是购买好几家的Token套餐。根据它们各自的擅长领域，以及我在测试中认为它们表现更好、更令我满意的场景，我在使用不同角色的Agent时，系统会自动路由到我预设分配的模型。

我的做法不是购买一个Token套餐来处理所有工作，而是购买好几家的Token套餐。

根据它们各自的擅长领域，系统会自动路由到我预设分配的模型。

这让我想到一项研究。2025年三月，Yue Meng团队用二百五十个机器人做了一个实验，测试如何在密集环境中让它们高效协作而不发生冲突。他们要解决的核心问题很具体，二百五十个机器人在自动化仓库里同时穿梭时，局部协调很容易陷入死锁。他们的解法是让一个中央单元生成全局调度表，统一决定机器人的通行顺序。但传统的集中式方法，其运行时间会随着问题规模急剧增加。于是他们创新性地使用了图神经网络变分自编码器（GNN-VAE）。简单说，就是先在小规模问题上训练一个"压缩地图"，把优质解法打包进潜在空间；真正需要调度时，再从这张地图里解压出几套方案，挑最省成本的那个。

实验结果显示，这种方法在处理二百五十个机器人的大规模问题时，不仅保持了高解决方案质量，而且速度远超其他基线方法。读到这的时候我愣了一下。这不就是我手头在折腾的事吗？我采用的"秘书Agent加专用Agent"架构，其实就是这种集中式协调思想的工程化实现。秘书Agent就像那个中央单元，负责全局调度和任务编排。

我越用越觉得，效率的关键不在于每个Agent有多卖力，而在于那个秘书Agent知道什么时候该派谁上场。

效率的关键不在于每个Agent有多卖力，而在于那个秘书Agent知道什么时候该派谁上场。

日常主力：四套Agent团队

现在这套多Agent系统是我的日常主力。秘书Agent会先读取记忆库来理解我的意图，然后回头跟我确认："老板，您真正想做的是不是这样？"达成共识后，它才开始编排手下的各个专用Agent，并为每个Agent配置好对应的技能。

真正耗费精力的是执行中的接力过程。秘书Agent会制定一份详细计划，明确谁做什么、需要哪些资料对齐、最后交付什么。我点头后，它们才开始执行。每完成一个阶段，秘书Agent会按照我预设的评分规则进行打分——达标就交给下一个Agent，不达标就直接打回重做。

全部执行完毕后，秘书Agent会用PPT进行汇报。我审阅后如果发现问题，它会进行溯源：找出是哪个环节、哪个Agent出的错，然后把错误丢回给那个Agent去反思。如果我对内容有修改意见，它也会先让负责的Agent去修改，改完后将这条教训记录入库，确保下次不再犯同样的错误。

后来，基于这套流程，我又根据工作需要，专门组建了用于写作的Agent团队、用于科研的Agent团队，以及一个负责AI FDE项目的Agent团队。

目前，我的大部分日常工作都依赖于这四套团队来完成。

日常办公团队

秘书Agent统领全局，下设研究、计划、写代码、写文章、审阅合同、法律建议等专用Agent

写作团队

主力模型：Claude Opus 4.6（文字质感）+ Kimi 2.6（中文写作）

科研团队

负责文献调研、数据分析、论文撰写等科研全流程

AI FDE项目团队

负责企业AI落地的现场部署与交付验证

最近，我又将这四套团队全部导入了WorkBuddy。与我在Hermes上的使用体验相比，WorkBuddy上的团队运作更加显性化，这得益于WorkBuddy本身的设计。它能让你清晰地看到团队中有哪些角色，以及每次任务执行时具体是哪些角色在工作。当然，WorkBuddy这个产品打包得比较紧，部署多Agent团队时的自由度不如Hermes那么高。在Hermes上，我甚至可以在每次切换Agent时，让它先出来做自我介绍，说明接下来要做什么、怎么做，包括它将调用哪个大模型。

蝴蝶效应与上下文

在使用过程中，我有了新的理解。Loop工程的关键，不一定在于约束有多好，或者Harness有多厚。我认为，要让它不偏离轨道，真正关键的突破点其实是你能给它多完整的上下文。

因为在循环过程中你会发现，哪怕某一步只偏差百分之五，这个偏移也会在后续每一步中被不断放大。

哪怕某一步只偏差百分之五，这个偏移也会在后续每一步中被不断放大。

这让我想起一个著名的数学现象。1961年冬天，美国气象学家爱德华·洛伦兹在运行天气预测模型时，为了节省时间，将初始数据0.506127简化为0.506，只保留了三位小数。他原以为这只是个微不足道的四舍五入，但几个月后重新运行程序时，他震惊地发现：两条原本几乎重合的曲线，在几个月后完全分道扬镳，预测出的天气截然不同。这个发现后来被称为"蝴蝶效应"——一只南美洲的蝴蝶扇动翅膀，可能在两周后引起德克萨斯州的一场龙卷风。

这种偏移从何而来？我认为，上下文不完整可能是一个重要原因。这件事之后，我在日常工作中特别注重上下文的采集。

被记录下来，才算、才能发生在AI里。

—— YC合伙人 Tom Blomfield

例如，我会使用AI录音卡，不仅用它记录与他人的会议交流，还会通过它的语音速记功能来记录我的一些碎片化想法，并在过程中通过文字补充、图片拍摄等方式，尽可能提供足够的上下文，包括上传相关文档。

过去，我们可能只在较长的对话、会议中，或者将相对完整的文档传给Agent，让它了解项目背景。但我们不能假定，在一个项目或一项工作中，上下文总是整块出现的。在我的工作场景中，超过百分之五十的上下文都是碎片化的。比如，开完会后，我和同事去吃工作餐，过程中他可能用手机向我展示竞品的图片或相关案例。

Loop工程实践，实际上是在与这个数学规律做斗争。在多Agent协作的长链条中，每个Agent百分之五的偏差，就像那只蝴蝶扇动的翅膀，会在后续的接力中被指数级放大。因此，上下文的完整性正是对抗这种混沌效应的关键策略，它为系统提供了更完整的初始条件。

由于我的工作性质，对话是创造项目上下文的主要方式之一。因此，我高频使用GetSeed录音卡，并让我的Agent定期检索，查看是否有新的录音产生。当它发现新的转录文本时，会提取相关文本存储到指定位置，并在此基础上总结出数条关键洞见，存入我的记忆库。它还会提取我的待办事项，同步到日程管理工具"滴答清单"，自动创建任务并归类到相应的项目文件夹。

压缩记忆系统

今年二月，Zhuoen Chen团队提出了一种认知启发框架，核心思路是"压缩记忆"。他们不再把原始token全部塞给模型，而是把长输入切成块，每块压缩成一张记忆卡片。随后，一个门控模块（你可以理解为自动筛选器）只挑选相关的卡片交给推理模块处理。实验结果显示，这种方法在多跳推理测试中保持了不错的准确率，还把能处理的上下文长度从7K扩展到了1.75M tokens。这是什么概念？相当于以前一次只能读几页纸，现在能一口气读完一整本书，而且峰值显存占用降到了原来的三分之一，推理速度快了六倍。

通过AI录音卡、图片拍摄、文档上传等方式采集碎片化上下文，并让Agent定期检索和整理，实际上就是在构建一个类似的"压缩记忆系统"。其核心是将信息结构化，通过项目文件夹和记忆库，Agent能够按需调用信息，而不是一次性接收所有内容。

上下文长度

从 7K 扩展到 1.75M tokens，相当于从几页纸到一整本书

峰值显存占用

降到了原来的三分之一

推理速度

快了六倍

上周，我让秘书Agent安排一次竞品分析，它就是这样调度的：研究Agent先搜集资料，写作Agent再产出文案，我最后只需在PPT里查看结果。

桌面上的工作伴侣