文章核心观点 - 文章围绕马斯克旗下xAI的Grok Bot展开，通过同题实测对比Grok Bot、WorkBuddy和Qoder CN三款多智能体协作产品，核心结论是多智能体已能承担研究流程中的具体工序，但产品竞争下一步比拼的是交付可靠性，即核查结论能否穿过每次交接准确落到最终文件 [10][31][39] - Grok Bot以12分49秒交稿，速度最快、收录论文最多；WorkBuddy用21分43秒交出最接近编辑底稿的正文；Qoder CN用14分42秒呈现出一次有价值的智能体交叉纠错 [10][29] - 三款产品共同表明多智能体已能承担研究流程中的具体工序，而成果质量仍要落实到读者结合自身专业水平进一步优化 [37] Grok Bot产品定位与功能演进 - 2025年8月11日，xAI正式发布Grok Bot，将其定位为一组可以持续工作的AI Teammates（AI队友）[5] - Grok Bot不像传统聊天助手那样主要围绕一个对话框展开工作，用户可以创建多个具有不同名字和职责的Bot，例如研究员、项目经理、运营专员，让它们各自负责一类工作 [7] - 主Bot会根据每日任务执行情况，帮助用户发现下一步工作，并主动提议接手，把需要决定的事留给用户 [7] - 这些Bot不必在每次任务开始时重新创建，能够保留各自的会话、工作偏好和长期上下文，还可以互相发送消息、进入群聊，将尚未完成的任务交给其他Bot继续处理 [8] - 10月14日，Grok Bot更新功能：用户可以给Bot的邮箱设置不同别名，例如专门接收新闻简报、购物收据或旅行信息，并让不同邮件分别触发预设的工作流程 [3] - 10月2日新增的主动提议能力，让主Bot能够根据已有上下文，发现可以继续推进的工作，并向用户提出接手建议 [9] - Grok Bot在10月2日公布了“主Bot主动发现工作并提出接手”的能力，例如在上午报告新增五篇调研论文，并生成一封等待用户确认的邮件草稿 [34] Grok Bot技术架构 - 支撑这套协作方式的是一台持久化的云电脑，同一账户下的多个Bot共用其中的文件、浏览器登录状态和命令行凭据，并拥有各自的操作界面 [9] - 前一个Bot搜集的资料，后一个Bot可以直接接着处理；即使用户关闭本机，后台任务仍能继续执行 [9] - 用户可以将完成过的工作流程保存为Skill，再通过Routine设置定期执行 [9] - 根据官方说明，Bot可以在用户关闭本机应用后继续工作，同一账户下的多个Bot共用文件、浏览器登录态和命令行凭据，各自有可并行操作的会话窗口 [33] - 云端执行并非Grok Bot的独有创新，多款类似产品也有云环境运行设定，例如Manus Cloud Computer、WorkBuddy企业智能体、Qoder Cloud Agents等 [33] 同题实测设计 - 测试要求三款产品围绕“大模型路由”为题写一篇综述，完成文献检索、方法梳理、数字核查和独立审稿 [10] - 该题目要求智能体能区分多个名字相似度极高的研究，也要求审稿意见落实到最终文件，还要求智能体能在分工、交接和纠错过程中都在交付物中留下痕迹 [10] - 测试指令要求使用多智能体协作机制，完成一份截至2026年10月15日的中文研究综述，主题为“大模型路由研究” [14] - 要求不同智能体分别承担文献检索、方法梳理、实验与基准核查、独立审稿等职责，由一位负责人整合结果 [14] - 最终交付包括：一篇约3000—4000字的综述、一张涵盖至少12篇原始论文的对照表、一个“尚无定论的问题”小节、简短的协作记录 [14] - 要求每项关键事实和数字附可打开的原始来源链接，区分论文报告的结果、独立基准结果和自己的推断 [15] - 无法核实的说法标为“待核实”，不要填补或编造引用 [16] - 完成前由未负责撰稿的智能体独立检查引用、数字、方法分类和结论边界 [17] Grok Bot实测表现 - Grok Bot先把任务交给“学术调研师”、“项目经理”和“文章撰写专员”三个具有名字的Bot，自己负责最终整合 [18] - 学术调研师给出19篇论文的对照表，并提前区分多个高相似度研究名字，项目经理核查数字，撰稿Bot收到材料后写初稿，学术调研师再对其审阅 [18] - Grok Bot给出了含有八份文档文件的产出，覆盖正文、对照表、开放问题、文献梳理、基准核查、审稿意见和协作记录 [18] - 独立审稿意见抓到了两个未经核查表格确认的百分数，撰稿Bot随后将其删去 [19] - 另一轮交接还纠正了两篇论文的arXiv编号，这些是可以从文件与会话互相对应的修订 [19] - Grok Bot用时12分49秒，速度最快、收录论文最多 [10][29] - Grok Bot的4个角色包含主智能体 [29] Qoder CN实测表现 - Qoder CN在任务开始后启动了三个检索子智能体分别寻找核心论文、基准与近期进展 [21] - 随后由方法梳理和事实核查两个角色接手，独立审稿者在成稿后检查 [21] - Qoder CN给出了包含四个文档的交付件：综述、论文对照表、开放问题与协作记录 [21] - 综述正文约19KB，约4000字，含问题定义、六大类方法分类、基准评估、LLMRouter贡献与局限、工业实践、技术趋势、开放问题 [23] - 论文对照表约10KB，包含15篇核心论文+5个工业实践的结构化对照表 [23] - 尚无定论的问题约4KB，包含10个开放问题的详细分析 [23] - 协作记录约11KB，包含完整的智能体协作过程、交接记录、发现的问题与修订 [23] - 检索阶段literature-search负责17篇核心论文，benchmark-search负责10个基准+评估体系，recent-advances负责2025-2026进展共50+论文+7个工业案例 [24] - 梳理阶段method-organizer负责六大类方法分类，核查阶段fact-checker负责8个数据点核查并发现4个需修订项 [24] - 审稿阶段independent-reviewer独立审查4个文件，发现fact-checker本身犯错（RouteLLM 85%）[24] - 核查者智能体参考RouteLLM论文，认为“最高节省85%成本”出处不明；审稿者继续找到项目仓库来确认项目这一表述 [24] - 论文表格中给出3.66倍的成本节省比率，两个数字的评测条件和计算口径需要分别说明，不能直接互换 [24] - Qoder CN用时14分42秒 [10][29] - Qoder CN的6个子智能体，另有主智能体 [29] WorkBuddy实测表现 - WorkBuddy花的时间最长，交出的正文也最像一份可继续编辑的研究底稿 [25] - 在文献检索、方法梳理、基准核查分别安排三个研究角色并行工作，由负责人整合初稿，再交给未参与撰稿的角色审阅 [25] - 最终综述围绕“路由信号”和“决策结构”组织方法，明确区分论文自报、独立基准、作者推断和待核实数字，读者能够顺着标注回到证据 [25] - WorkBuddy用时21分43秒 [10][29] - WorkBuddy的5个角色包含主智能体 [29] 行业竞争格局与趋势 - 三款产品都完成了综述、论文对照表、开放问题和协作记录，审稿环节也留下了可追踪的修订 [31] - Grok Bot以速度和检索覆盖见长，WorkBuddy的正文最适合作为编辑底稿，Qoder CN展示了审稿者纠正核查者的交叉检查 [31] - 角色数的计数口径并不一致，不能用来推断“智能体越少，运行越快”，耗时包含检索、等待、审稿和交付，并非纯模型推理时间 [29] - 对比WorkBuddy和Qoder，Grok Bot展现出产品形态的另一面，把智能体放进了一套持续运行的云环境，Bot可以跨会话保留材料，也能接着同伴的工作往下做 [37] - 长期任务能否在故障后恢复、共享资料如何控制访问、每项任务消耗多少资源，都成为产品能力的一部分 [37] - 交互方式也在变化，Grok Bot把具名Bot、工作状态、例行任务和交付物放到同一个界面，用户可以看见谁在处理任务，并在需要判断时接手 [38] - 未来衡量主动提议能力，还要看建议是否切中需求、是否频繁打断用户，以及哪些动作必须停下来等待授权 [38] - 马斯克近期在X上提出，Grok Bot今后会按任务选用包括第三方服务在内的后端模型 [38] - 这可能意味着产业将进一步细分，模型研发与智能体产品研发的分工将更清晰，两类团队也仍会向彼此的领域延伸 [38] - 从智能体产品角度来看，决定产品竞争力的是这套流程能否稳定交付，并让用户看清数据流向、任务成本和结果依据 [38] - 三款产品显著的不同在于Grok Bot已把云端常驻、跨会话接力和主动提议带进同一工作环境 [39] - 三款产品仍各有成稿缺口，说明检索、核查与审稿的成果还需要准确进入最终文件 [39] - 随着模型和Bot可以按任务组合，产品竞争将越来越取决于这条链路能否持续运转：任务中断后接得上，关键决策由用户把关，过程与成本查得到，成品经得起专业复核 [39]

文章核心观点 - 2026年Agent产品正从专注任务转向专注人，但更本质的转变是Always-on Agent成为标配，同一套常驻底座根据接入上下文不同特化为个人管家或团队同事 [6][7][17] - Agent产品按“人要管多少事”形成光谱，从Claude Code等生产工具到OpenClaw、Hermes，再到Always-on Agent，复杂度不断从人转移到系统和模型 [10][13] - Always-on Agent需解决三大核心问题：主动（何时醒来）、权限（哪些能做）、记忆（留下什么如何接着做）[15] - Grok Bot在唤醒机制、状态恢复、权限管理、记忆维护四个卡点上做出实质性工程推进，成为Always-on Agent的架构标杆 [18][24] - 个人Agent特化需在记忆、主动、权限三方面深度调整，Muse在个人方向走得最远 [76][78] - 办公Agent与个人Agent底层同源，未来可能合流为统一长期入口 [116][117] - 商业模式上个人Agent单卖困难，打包进办公AI付费套餐是更实在路径 [126] 一、Harness演进与Always-on Agent核心框架 - Agent产品光谱从左到右：Claude Code/Codex（人盯每一步）→ OpenClaw（常驻但维护费劲）→ Hermes（替用户做决策但写死规则）→ Always-on Agent（决策交给模型）[10][12][13] - OpenClaw让用户首次体验“养Agent”，靠Heartbeat定时醒来，用USER md和MEMORY md记住用户，但部署、技能安装、记忆维护都需用户自己来 [10][11] - Hermes在2月底首发，连续几周霸榜GitHub Trending，功能与OpenClaw几乎相同但控制权转移：任务调5次以上工具或被纠正过就自动存技能，每聊15轮硬塞反思指令 [12][13] - Hermes将决策写成死规则：5次工具调用、15轮对话、85%压缩阈值、危险命令黑名单，全是开发团队提前拍板 [13] - Always-on Agent核心是常驻系统加能拍板的模型，Agent存在不依附于一次对话或一台开着的电脑，合上电脑后仍记得事情进展，有消息能被叫醒接着推进 [13] - 要真正一直在线需解决三件事：醒得对不对（主动）、要不要老来找你（权限）、记不记得住（记忆）[15] - 接入不同上下文决定Agent替谁记事、为谁主动、凭什么行动：个人Agent盯日历邮件聊天账单，团队Agent盯群聊项目文档工作软件 [17] - 未来常驻在线、握着上下文和权限、能自己往前推事情的Agent大概率成为标配，OpenAI、Meta、xAI在记忆分层和常驻架构上已摸到相似答案 [17] 二、Grok Bot：做扎实“一直在线” - 8月11日SpaceXAI发布Grok Bot测试版，最初是公司内部原型，后在销售、运营、工程团队传开 [20] - 用法：建几个有名字有分工的Bot像给同事发消息一样派活，每个Bot背后有云端电脑，浏览器文件系统终端一应俱全，没有API和MCP的网站能直接登进去点 [20] - 合上电脑它会接着干，只在需要拍板时回来找，用户可当面操作一遍它看完整理成技能以后定点自己跑，几个Bot之间能互相发消息由“幕僚长”Bot统一调度 [20][21] - Grok Bot走OpenClaw那条线，先不管服务谁，把“一直在线”本身做扎实 [21] 卡点一：唤醒太死板 - OpenClaw靠Heartbeat，进程一直开着每隔一段时间醒来看一眼，毛病是醒得不是时候且寄居在一台机器一个进程里，电脑一合进程一崩就不在了 [25] - Grok Bot不按点醒按事醒，Agent大部分时间在睡觉，云端电脑也在睡，Slack消息、邮件、会议开始、后台任务完成才是闹钟 [25] - 被叫醒后从数据库搬出状态，需要上网再叫醒云端电脑，干完活两个一起躺回去，对话记录记忆定时任务全部存回数据库 [25] - 事件先过路由去掉重复分轻重，用户亲自发来的消息可插队直接打断手上活，群聊和后台任务排队，几条挨着来的打包成一轮处理 [29] - 每次醒来处理完事判断值不值得打扰主人，大多数事情一天同步一次就够 [29] - 心跳是闹钟事件是门铃，从到点醒变成有事才醒，Agent才从开着的进程变成随时在又不吵你的助手 [31] 卡点二：容易崩溃状态难恢复 - Always-on本质是状态一直在叫醒后马上接着做，OpenClaw跑在本地电脑上走错电脑崩了重启后信息丢失恢复非常花时间 [32] - Grok Bot把Agent循环跑在服务端，服务端电脑是Firecracker虚拟机可随时拍快照关机原样恢复，坏了推倒重建，状态不在电脑上换一台Agent毫发无损 [32] - 加持久化工作流，普通任务队列做到第三步服务器崩了重启后从第一步重放可能同一份邮件发两遍单下两次 [32] - Grok Bot用开源工具Temporal记下每一步，崩了之后直接复原到从第三步接着来 [35] 卡点三：要你确认的事太多 - 编码Agent阶段人在云上并行开好几个但人还是瓶颈每条命令都得盯着批，OpenClaw权限基本只有两档：事事来问或全放开 [36] - Hermes折中是写死危险命令黑名单拿正则匹配，还有一种回来找你是权限卡住：没有API的网站进不去没接MCP的服务用不了 [36] - 一个动不动就回来找你的Agent再怎么一直在线也没用，还是得守着它 [37] - Grok Bot从三个方向把人解放出来：第一给它一台自己的电脑，Agent在虚拟机里干活不碰你的电脑，没有API的网站自己登进去点，出岔子影响关在那台机器里 [38] - 第二让Agent碰到问题先自己想办法，Grok Bot定能力阶梯：先翻对话已知的，不够调插件MCP或API，还不够上网搜，再不行开浏览器自己查，最后动用整台电脑写脚本跑命令搭工具 [39] - 浏览器里先读最省的无障碍树和HTML，实在不行才截图按像素坐标点，全失败比如碰上两步验证或人机验证才回来找你 [39] - 判断该用哪个工具试到哪步算“实在不行”这条命令放不放行，Hermes拿黑名单兜底Grok Bot交给模型 [39] - 第三让模型替你审，每条命令执行前先让另一个模型审一遍叫auto review，Lee说让模型审命令比让人一条条批几百条更安全因为人会累 [41] - 真正需要你的只剩登录付钱发邮件这类撤不回来的几处，授权完备时密码凭证走产品流程压根不进模型对话 [41] - 人从“每一步都批”退到“只在关键处点头”，这是光谱上往右挪的最大一格 [41] 卡点四：记忆维护成本高 - OpenClaw记忆是被动的上下文快撑爆才顺手存档，对话越拉越长模型越容易忘掉前面的事表现越来越差，到上限只能压缩而压缩有损 [43] - Grok Bot思路分两步，第一步少往主Agent里塞：主Agent只当总调度对话尽量清爽，跑命令做工具调用交给子Agent干完只带结果回来 [46] - 子Agent也省上下文，工具说明只放名字，工具输出直接写进外部文件，真要用再去文件里读完整说明 [46] - 第二步精炼压缩分三层：核心事实每次对话都带着也要定期清理，带日期的日志问“上周干了啥”直接翻日志，临时便签只在一两个小时内有用用完就扔 [48] - 剩下一切放文件里需要时让模型自己用grep这类命令去翻，什么时候压缩让模型自己规划 [50][51] - 长上下文太贵每来一条新消息整段对话历史重新发给模型，唯一绕路是利用KV Cache，模型厂商对缓存过的上下文收费很低 [51] - OpenClaw爆火时Harness还没为上下文缓存做优化导致缓存成片失效账单爆了，Grok Bot大幅优化：前缀纹丝不动系统提示词工具定义能不改就不改让过去上下文尽可能命中缓存 [51] - 另一招趁热压缩：聊了十几万token走开后模型厂商缓存还会热一阵可能10分钟可能60分钟，Grok Bot在这段时间把长对话压成摘要因为这时候压缩最便宜 [51] 三、Always-on之后：多端Agent与前台简化 - 四个卡点拆完后台跑着的Agent已能做到不打扰你的情况下做好很多事情，前台缩减成一个聊天框变得可能 [54][55] - Lee说法：模型越强界面反而越简单，过去模型靠不住产品堆满diff视图审批弹窗配置面板让人盯着每一步，现在Agent能自己把活干完人只需交代事情等结果 [55] - OpenClaw时代虽在WhatsApp Telegram里聊但要不断来回确认还要从COT里挑错，说是对话框但字数多得吓人 [55] - OpenAI在ChatApp里增加生成式UI让聊天框更好用：登录网站弹出专门登录框接1Password，付钱跳Stripe Link或X Money，发邮件发Slack生成草稿卡片改完点头才发 [57] - 聊天框负责说话确认和输出交给按需生成的界面，人越来越少需要确认的关键点被做成点一下就行的按钮 [57] - 这样多端才真正能用，不然后台越强人在前台翻消息翻得越累 [58] 四、把模型练到能拍板 - Grok Bot重要进步在于把更多机制交给模型判断，Harness工程里埋下基本能力：睡眠唤醒持久化工作流独立虚拟机缓存和压缩，把能确定的事交给系统 [59] - 但判断值不值得叫醒你该不该回来问你哪句话值得记住，这一半写不成规则只能交给模型 [60] - Hermes时代答案是靠不住所以写死规则，Grok Bot时代解法是让它学到能信 [62] - Grok Bot有两个学习循环：内循环天天跑，Agent犯错比如调了不该调的工具就变成评测用例，团队修Harness改提示词或查推理问题测过再上线 [63] - 外循环每隔一阵转一次，把内循环积攒的问题和用例用来更新训新模型，用SFT让它看大量Harness样例熟悉工具有哪些，用RL让它学会听指令在几百个技能里挑对那一个在网页上点对地方 [63] - 新模型上线判断又准一截交给它的事就能再多一点 [65] 五、个人Agent：从Always-on到上下文特化 - 同一套底座可替团队盯工作也可替你盯生活，可催项目进度也可提醒孩子报名截止日期 [68] - 五款产品各站光谱一个位置：OpenAI dots、Manus Cue、Instinct、Meta Muse、Grok Bot [69][71] - OpenAI dots是9月29日DevDay压轴底层GPT 6 Astra，在ChatGPT桌面端布置完任务关电脑几小时后在Slack里@你汇报，演示中潜伏公司群看到客服报Bug自己读报错定位修复跑测试最后给工程师提PR [71] - Manus Cue 9月28日上线给每个Agent配电话号码邮箱云电脑外加受预算管着的钱包，能直接打电话给餐厅订位跟客服语音砍价，好几个Agent拉群分头规划海外旅行 [71] - Instinct创始人Noah Shinn 23岁是Reflexion论文和τ-bench合著者，公司一个月估值翻四倍，把App都扔了只用短信iMessage和电话跟你说话 [71] - Instinct演示A2A愿景：两个人要约时间双方Instinct在后台直接加密谈人连来回拉扯都省了 [71] - Muse在个人光谱走得最远，日历备忘录聊天软件连财务应用都要接，借Stripe Link填表结账续费跟商家谈账单自己全包 [72] - 在WhatsApp发一句语音能在云上闷头跑几个小时把整趟差旅订好 [73] - 五款摆一起渗透方向不同但底座同一套，往哪推推多深是各家自己的选择 [74] 个人Agent记忆特化：从记住工作到记住你 - 通用版记忆三层：核心事实日期日志临时便签，剩下放文件，能记住对话里核心事儿 [80] - 特化到个人要记住和你这个人相关的一切事情，今年二季度Karpathy用Obsidian搭个人Wiki火过一阵可算个人化记忆工程起点，底层一堆Markdown有资料摘要实体页概念页综合分析，回答问题前模型先读总目录index md再按图索骥翻相关页 [81] - Instinct隐私政策显示会常态化读文档邮件甚至音频，具体怎么做没公开，看得最清楚的是Muse [81] - 9月22日开发者Peter James把Muse文件系统解包，发现Muse用Markdown存记忆正文用Postgres库存证据状态和索引再由后台Agent一直整理 [81] - Muse的Md记忆库五花八门，有短日志记忆也有对短期记忆整理后形成的持久可更新记忆区块 [81] - 形成从短期到长期再到反思的完整链路 [83] - 其他区块更小甚至有具体领域记忆文档供具体场景取用相关记忆和偏好，例如购物画像memory/shopping/PROFILE md由购物任务直接读取排除在通用记忆索引之外 [83] - 根据持久记忆区块信息模型写出指导行动的MEMORY md，从材料中精选重要事实偏好和承诺形成便于后续调用的简明备忘录 [83] - 外部还有专门反思互动的动线，dreams/保存对近期互动的反思再将其中的经验整理成综合行为指导影响以后怎样回答提醒和与用户相处 [83] - Postgres库是向量库既管理记忆也保存应用运行数据，主要起快速索引到具体任务细节的作用 [86] - 数据包括具体记住了什么来源和当下是否有效状态，比如邮件说项目10月20日截止后来来一封说延到27日前一条标成“已更新”后一条才算“有效” [86] - 有单独索引数据连接Markdown中细节记录正文切片和索引 [90] - 记忆流程：用户与Muse互动产生可用上下文Muse挑选值得保留信息即时写入记忆文件，后台对照原始消息核验更新精选要点用户画像关系资料和检索索引 [91] - 下次问题到来时系统召回相关记忆由模型据此回答或行动，新互动补充或纠正已有认识进入下一轮记录与更新 [91] - 夜间反思把近期互动经验整理成综合行为指导调整下一次与用户相处方式，若用户要求遗忘系统确认清理范围后清理相关正文和派生资料撤回结论刷新索引并检查可能重新写回这些信息的后台任务 [91] - Muse演示例子：只说一句“准备开学”就自己去翻学校邮件和网站把散落各处信息拼到这一个目标上 [94] - Muse和Grok三层记忆底层没差别：核心事实对应MEMORY md和USER md，日期日志对应memory/里日记，剩下靠翻文件，多出来的是个人部分是画像关系和反馈反思 [95] 个人Agent主动特化：从有事才醒到自己找事 - Grok Bot也有主动性会被新信息叫醒醒了先判断值不值得打扰你，被搁下的对话会跟进卡住的交接会催进度 [98] - 工作场景上下文主要来自工作库，对话里工作本身自带目标修Bug推项目赶截止日期，基础版三样能力基本够用接进来就是同事 [98] - 个人不一样，日历聊天邮件账单里没人替你写好工单，目标散在上下文里得Agent自己去发现 [98] - GitHub用户win4r利用Muse运行环境部分文件快照整理出MuseAI-Skills仓库，里面有Goal md说明有一整套围绕目标的产品设计 [98] - 目标可以是你明说的存进Goal md驱动模型一步步规划记录进展，也可以是系统从上下文里找到目标再给用户建议 [98] - OpenAI Dots公开Proactive research，官方文档描述以固定频次主动去做形成新目标/建议，后台Agent翻你允许它看的信息记私人笔记把新变化和以前工作串起来报告给主dot再由主dot来问你给你建议 [99] - Muse解包里这件事分两块：Studying每天夜里围着已有目标做功课找推进办法，主目标推不动还会把你曾随口提过的事翻出来作为候选目标 [100] - Idea curation每天根据历史生成一批建议按可行性跟你合不合拍新不新鲜打分排序推给你，你点采纳就成了新目标 [100] - 目标源源不断冒出来，定下目标后系统每次醒来都去找相关新信息拆子任务设定时任务一点点往前推 [100] - 演示里Muse从学校邮件发现孩子体育选拔报名快截止主动给家长发消息 [100] - 从有事才醒到自己找事是个人Agent特化在能力上跨得最大的一步 [102] - 目标系统驱动的主动性规划和任务驱动的/goal不相同，任务往往有更大时间跨度，但核心拆解任务补充信息思考解法等中间件逻辑非常相似，整体和Grok Bot能力阶梯也有类似之处 [102] - 依靠唤醒机制这套逻辑可被应用到更长程时间框架下 [103] - 尽量少打扰用户只在需要决策时询问，比如普通检查结果先留着不通知而快截止的报名值得打扰用户就去推送提醒 [103] - 一个主动介入帮你分析问题同时给出主动建议在接受目标后静默帮你处理完事情的个人助手就有了产品基础 [103] 个人Agent权限特化：模型够不够格的赌局 - 个人层面权限非常要命因为会产生直接C端后果比如花钱，不像在沙盒里工作Agent搞砸了直接复位即可 [104] - 靠用户自己在个人Agent初期授权以及后续交互模型能搜集到一些授权范围信息，但模型对权限理解天生爱往大了走 [104] - 2026年5月AuthBench研究发现模型很难一步到位给出最小权限经常给多了，论文提出先推演需要哪些权限再一项项收窄的两步法效果明显好转 [104] - 个人Agent选择路径是做看门Agent，早期Hermes有smart模式在后台用辅助模型专门评估风险遇到拿不准操作弹窗问