你的Personal Agent 如何真正跑起来？Agent实战指南

作者：spike，腾讯游戏数据团队负责人

导语今年以来我一直在建设自己的分身，也在工作中用得非常多。前面几篇聊到了context、个人bias和判断带宽，这次想具体讲讲，我平时怎么用，以及这套东西是怎么一点点搭起来的。

现在已经养成了一个习惯，想到什么，就找一个当时顺手的分身聊一下。如果是在电脑前的时候，可以跟它深入讨论、查材料、改文件、跑实验；离开电脑，也可以从手机上的企微/Htalk里继续。有些分身在自己的电脑上，有些在云端，我也花了不少时间，把它们能用的资料、近期工作和记忆接起来。

我经常只有半个想法，还没整理成一个完整问题。或者刚收到一份材料，觉得跟手上的事情有关，但还没想清楚有什么关系。先说给它听，它去找相关背景，我们再一起往下想。需要查的继续查，能试的就动手试，没想完的也可以先留下来。

这件事对我很有意义。比如，刚开完一个会，为什么改了主意、哪句话让我有疑问，当时都记得比较清楚。如果要等回到某台电脑，再找到原来的会话重新讲，可能就只剩一个很简略的结论，甚至忘了继续聊。

所以，让它随时能用，并且能接着之前的事情往下做，我一直挺在意的。这些随手聊的内容里，有很多是在正式文档里不会留下来的背景和取舍。

上图按当前用法整理的结构示意。共享资料和近期记录帮助接续工作，各个分身仍有自己的会话和运行状态。

举个例子：9月中旬有一天，我口述了几个当天的讨论（没开会议也没录音）。其中一个问题是，怎么进一步让用AI更深入的同学，带动其他人。我当时在想，像游戏里有人升级快、有人升级慢，产品能不能帮助那些先跑出来的人，进一步带动团队。

同一天，经分团队的同学，给我同步了一个他们的实践。他们把数据服务Agent挂载在内部的HTalk ，开发了个WorkBuddy专家，接到了用户自己的WorkBuddy里。业务团队的用户在原来的工作流程中需要数据，只需要在自己的WorkBuddy里提需求，需求就会进入一个有我们经分同学，也有数据Agent的工作企微群；中间补充背景、确认口径，完成后再把结果拿回去继续用。

我当时关注的是，这个做法把原来散在几个地方的context连起来了。用户自己的分析、提交的需求、经分的执行、群里的沟通，都能沿着同一件工作接下去，而且不用切场景。

分身读完后提醒我，这个案例其实也是前面那个我在思考“传染机制”的一种具体实现。

经分同学已经把自己的知识、工具和处理方法建设进了Agent。其他同学在原来的工作里（WorkBuddy）调用这份能力，就能先获得帮助，过程中再补充业务背景、提出反馈。他们不必先学会经分同学整套建设方法，也不需要学习怎么使用经分的Agent，也不需要使用Htalk，就能开始受益。

这让我把原来的问题又往前推了一步。带动别人，除了把方法教给他，还可以让他更无痛得先用上已经建设好的能力（不用学习新工具、新Agent的使用）。产品要支持的事情，也就更具体了：熟练者能不能方便地把能力交出去，使用者能不能在自己的工作里用起来，出了问题能不能找到人，反馈能不能再回到维护者。

第一件事都是我自己讲的，第二件事情是经分同学在群里同步我的，但口述时，我确实没有把它们连在一起。但是跟分身讨论之后，分身可以帮我关联起来，这样我手里就多了一个能继续看产品、看案例的角度：哪些经验需要别人学会，哪些能力可以先让别人用上，两条路怎么配合，且有一个具体的案例。

还有一些事情，会从想法，能快速直接往实验走。

比如再举一个例子，最近我在关注Jev模型，想看看它能不能帮我先判断工作群里的消息：哪些需要我关注，哪些可以让Agent准备一下，哪些应该等已有负责人处理。

我把一个Jev模式的小模型在本机跑起来之后，让cb-a分身结合我的背景，通过HTalk读取相关消息，整理样本、写调用脚本，跑几轮测试，再把有分歧的地方拿出来看。小模型负责给出候选判断，cb-a分身负责组织实验和检查结果，我来校准那些跟实际工作有关的取舍。

然后想法就直接可以进入实验了，第一轮实验后，分身拉到的消息里，有三条消息，我给了很具体的反馈。

一条是我问一个方案的实际应用情况，同事说已经在用了。我的意思是，还可以帮我收集具体怎么用、效果怎样，必要时问详细一点。只把它归为“知道了”，没有接住我想了解什么。

另一条是有人报告问题，已经明确找了对应的负责人。这时我希望先让负责人处理，Agent不需要因为看到了问题，就再替我接一遍。

还有一条，我请同事比较两份材料，对方回复“好的”。这时值得记住的是，他已经承接了，还没有反馈结果。后面要跟进，不能把这句“好的”当成事情已经完成。

把这些说清楚之后，我们又调整了判断选项和示例，拿回去测试。有些地方改善了，有些仍然不稳定。甚至只调整候选项的排列顺序，也会影响部分结果。这次还没到可以放心自动处理的程度。

但这轮工作已经让我更清楚地看到，所谓“理解我的bias”，到底要落实在哪里。它要知道这件事当前到了哪一步，我在其中是什么角色，谁已经负责了，以及我希望它补上的那一步是什么。“主动一点”这样的要求太宽了，真实工作里，有该主动了解的，也有该记住等待的。

这个案例里，我只给了想法，读群聊资料上下文、选取组织样本、编写适配的调用模型的脚本、保存返回、检查错例，分身都能直接开始做。我主要参与的是，想验证什么，哪些判断不符合我的意图，结果是否足以支持下一步。一个想法就有机会很快进入验证，哪怕最后发现暂时还用不好，也会比一直停留在讨论里多知道一些东西。因为他够懂我。

能这样做，跟我给分身准备的工作环境有很大关系。

我让它工作的地方，本身就放着我持续积累的资料，现在主要是一个仓库。我的背景、当前关注、过去的讨论、会议记录、一些外部材料，以及做过的实验和产物，都在其中。工作群里的信息，通过HTalk按权限去取；它所在的环境也有文件、代码执行和其他工具能力，具体能做什么，要看那个环境接了什么。

所以我跟它说“看看这个”，有时是让它回去找原文，有时是对照几次讨论看判断怎么变了，有时可以继续动手验证。我不用每次先把材料全部整理好，再一段段复制给它。

当然，资料放进去了，它也未必就能用好。刚开始我也想过，把所有重要的东西都让它读一遍。后来内容越来越多，默认带进去的东西会互相干扰，旧重点也容易压住新问题。

现在我会把这些内容分开处理：相对稳定的背景和取舍、当前正在推进的事、完整的历史材料，各有自己的位置。近期进度及时留下来，旧材料通过索引按需找，需要核对的时候回原文。每次默认读的内容要控制，历史细节仍然保留。

比如只留下“最后决定做A”，下一次它很容易理解成我一直偏好A。但当时也许只是资源不够，或者另一个方案有个前提还没验证。于是我会要求把为什么这样选、讨论过什么别的办法、后来哪里改了，也尽量留下来。条件变了，才有机会重新判断。

分身本身怎么调，也是在用的过程中逐步摸索的。

早期它回答一次不满意，我就容易加一条要求：不要过度赞同，不要给空泛建议，不要回避矛盾。加多了之后，它越来越小心，但遇到新问题还是不知道怎么取舍。

后来我把这些要求拆开了。我的背景和当前重点放在USER里，遇到冲突时更在意什么放在SOUL里；文件写到哪里、哪些动作需要确认，放进操作规则；某一类任务怎么做，单独整理成SOP或Skill，遇到这类工作再读。这样某个具体任务里的要求，不会一直干扰其他事情。

现在觉得它不对劲，我会先让它说清楚，刚才怎么理解我的目标，差异出在哪里，再给修改建议。也可能只是这次少了一点背景，补上就行，不必动长期规则。

比如写文章，我希望严谨，它却把不够确定的整段推导删掉了，文字很稳妥，原来想讨论的问题却变小了。我就得把取舍讲出来：观点可以保留，事实和推演要分清楚。然后看下一篇、换一个题目，它能不能处理好这个关系。

当场改对一句话，和下次遇到类似问题能做对，是两件事。 所以我会看后面的真实工作，有时有效，有时还要继续调。这也是我愿意花时间跟它解释“为什么”的原因。

多设备、多分身这部分，也踩过不少坑。

3月份开始，我就在两台电脑上用同一个仓库，后来又把它用CodeBuddy，接进了带企微/微信入口的Claw。后续的使用过程中，偶尔出现两边都说记下来了，结果一个写在工具自己的目录，另一个写在仓库的memory目录，双方根本没在读同一份东西。后来才把路径统一，写进操作约定。

3月27日的原始记录。当时正在把已有资料和规则接进另一个工作空间；图中的初始化方式后来也继续调整过。

再后来，我希望离开电脑之后也方便使用，就增加了AnyDev的云端分身，减少对某一台电脑在线状态的依赖，也实现了同步。同步过程中也遇到过新文件传过去了，已有记录却没有及时更新的问题。看起来两边都有资料，实际上读到的版本可能不一样，类似这些都需要一点点处理。

还有一个更容易忽略的问题：即使读的是同一份仓库，两个分身也各有自己的会话Session。刚才我们为什么否定一个方案、哪个问题还在犹豫，如果只留在当前会话里，另一个分身就未必知道。

所以除了长期记忆，我还让各个分身留下近期的工作状态，仓库里叫live。它记录刚处理了什么、有哪些变化、哪里还没结束，需要时再回到完整笔记和原始材料。另一个分身接手时，就有地方去找这些线索。需要定向交接的，也可以留在各自的收件箱里。

几个人同时改一份文件都会有问题，几个Agent也一样。谁写自己的近期记录、谁维护共同文件，追加前先看最新内容，保留写入来源，这些后来都逐步有了约定。尤其是还在讨论的推断，不能因为被写进记忆，就变成我已经确认的结论。

所以换设备、换工具时，我希望它能找到的，除了资料本身，还有这件事目前到了哪里，哪些判断已经确认，哪些仍然值得继续讨论。现在仍然会有需要补背景的时候，但重新开始的成本已经少了很多。

某CVM上的live示例

我觉得这也解释了，为什么入口方便和积累充分会相互影响。越方便继续聊，我越愿意把刚发生的事情和没想完的问题交给它；这些背景留下来，下一次它又更容易理解我在说什么。这个过程持续发生，分身才会逐渐进入日常工作里。

用久之后，还有一种我很喜欢的方式，叫“洗澡时刻”。

最开始的想法挺简单。人有时候洗澡、散步，暂时不急着解决一个具体问题，反而会把之前没连起来的事情想通。我就想，让分身也试试：先放下手上的明确任务，看看最近这些事情之间，有没有我没注意到的联系。

当然，它得先有东西可看。

一部分来自前面讲的日常积累：工作讨论、会议记录、随手想到的问题，以及我们一起做事时的补充和纠正。尤其是还没想完的事情，我会尽量把当时为什么卡住、有哪些不同考虑留下来。

Htalk里唤起分身启动洗澡时刻

另外，我还接了一些RSS信息源，涉及AI工程、产品、商业、组织管理，也有跟我观点不太一样的作者。通过自动化定期抓取新内容，分身先做一轮筛选，留下来源、摘要，以及为什么可能值得我关注。我看到有意思的，会继续让它读原文，结合手上的问题讨论。有些只是当天看过，有些值得进一步整理进知识库。

这两类材料，处理方式也有点区别。外部文章会提炼观点，保留出处和适用背景；我自己的思考和讨论，会更在意保留推导过程。只记一个结论，后面很容易不知道当时为什么那么想。

所以有了上述这些积累，我跟分身说一句“洗澡时刻”，它就知道这次先不用赶着交付什么。它会从最近的工作、当前关注和未完成的问题开始，沿着线索回看更早的记录，也可以把相关的外部材料放在一起看。

比如，两件看起来没关系的事情，是不是遇到了同一种问题；我最近的一个决定，跟之前坚持的判断有没有矛盾；新看到的一个案例，会不会改变某个一直没验证的前提。

一般先给几个观察，把它为什么想到这个联系讲出来。我再挑有意思的继续聊。有些确实是硬凑的，指出来就好；有些第一眼没什么感觉，往下追问几轮，才发现值得认真想。

有一次，它回看了几周的讨论，提出一个怀疑：我们是不是太习惯用同一套框架解释新材料了？每次看到新的产品、文章、管理案例，最后都能归到原来那几个判断里。看起来理解得越来越通，但有没有一些不同的东西，被我们忽略了？

这个提醒也包括RSS。引入外部信息之后，如果每篇文章都被解释成“又验证了我原来的想法”，那还是可能绕回自己熟悉的框架里。所以我也会让它看，哪些观点跟我不同，哪些现象是现有想法解释不了的。

讨论完，有价值的内容我会让它整理下来，保留从哪些材料想到这里、中间怎么推、我补充或否定了什么。还没想清楚的，就明确留作待讨论，不急着变成长期结论。

这些记录以后又能被找到。过一段时间，有了新的工作、新的外部信息，之前没想完的问题就有机会继续往下走。

我喜欢这个过程的地方，是它有时能在我没有明确提问的时候，先帮我发现一个值得问的问题。至于这个问题有没有价值，最后还是要一起讨论，必要时回到实际工作里验证。所以我觉得“洗澡时刻”是一个很好的分身理解我的bias 的实现，因为prompt就是一句“洗澡时刻”。

几个分身之间，有时也会给出不同的解释。它们参与过的讨论不完全一样，模型和运行环境也可能不同。我会把一个分身的意见拿给另一个看，再比较分歧在哪里（偶尔我也在我的spikes的群里，跟分身们一起讨论）。

比如有次我觉得，最近跟某个分身聊少了，重新解释的成本变高。讨论到后来，我们把“不了解我”拆开了：有的是不知道这件事刚推进到哪，有的是旧资料没更新，还有的才是对我的取舍理解不够。分清楚，后面才知道该补状态、更新记录，还是拿具体问题继续校准。

这个过程中，我仍然要看依据。几个Agent都赞同，也可能是读了同一份有问题的摘要。我们就遇到过，还在讨论的推断被提前写成我的结论。另一个分身再读到，就可能把它当成确定的前提往下推。前面那些来源和确认状态的约定，也是在防止这种事情。

多个分身有额外的同步和维护成本。我觉得先有一个能持续参与真实工作、接受纠正、接着上次往下做的Agent，就已经可以探索很多事情。用到哪里觉得受限，再继续建设。

回头看这半年，对我比较大的变化是，想到一个问题时，更容易马上开始；决定往下做时，分身可以把查找、整理、执行和验证的一部分实际接过去；过一段时间再回来，之前花过的精力还能继续用。

我仍然要参与判断，也要花时间纠正它。但越来越多的事情，可以带着我的背景和关注点，先被认真处理一遍。我再把精力放在有分歧、需要取舍、或者出现了新东西的地方。同时，它也会把一些我没连起来的事情、没看清的前提带回来，让我调整自己的判断。

这也是我一直愿意投入时间的原因。有些讨论结束时，我们多了一份材料；有些是把原来的问题想深了一点，有些已经动手验证过了。而这些过程留下来以后，又能成为下一次工作的起点。