AI代理选型指南：Grok Bot、Muse、Dots的能力边界与开放范围

过去大半年问我这三款 AI 代理到底选哪个的人越来越多问题本身却常常问偏了。Grok Bot、Muse、Dots 这三个名字放在一起很多人第一反应是拉一张功能清单打勾比大小谁的工具多、谁的回答快、谁更便宜。真正上手跑过几十个任务之后你会发现决定你能不能长期用下去的往往不是它能做什么而是它的能力边界在哪里、它的开放范围有多大。边界决定了你什么时候会撞墙开放范围决定了撞墙之后你是绕过去、拆掉还是只能换一条路。这篇就按 2026 年 10 月这个时间点的观察把三款 AI 代理放在同一套坐标里拆一遍讲清楚各自的定位、工具调用的深浅、记忆与数据的出口、权限与审计的松紧以及同一件事交给三家分别跑一遍会发生什么。适合正在做选型的技术负责人、想把代理嵌进自己工作流的独立开发者也适合刚接触 AI 代理、还在搞清楚代理和聊天框区别的新手。1. 三款代理的定位差异与选型底层逻辑1.1 三种开放哲学先看清再谈功能把 Grok Bot、Muse、Dots 摆在一起最容易犯的错是当成三个同规格产品比参数。它们其实代表三种不同的开放哲学用生活里的东西打比方Grok Bot 像开在人流最密路口的便利店货不全但永远开着、结账快卖的是此刻的信息Muse 像一间带素材库和排版台的工作室进去要坐下来干活产出的是能直接交付的长内容与多模态素材Dots 像调度中心它自己不一定干活但它知道该把哪一步派给谁、什么时候该停下来等人签字。这个差异不是营销话术而是会直接体现在你配置它的方式上。理解这一点之后选哪个这个问题就会自然变成我的任务形态更像哪一种。你每天要做二十次快速查证和短回复Grok Bot 的实时性和响应链路就是刚需你要出一份两万字的行业长文或者一套风格统一的图Muse 的长上下文和素材一致性就是刚需你要让代理每天早上自动跑一遍固定流程、中间还要有人审Dots 的编排能力和节点控制就是刚需。三个方向没有高下只有匹配度。我见过不少人踩的坑是拿任务形态 A的需求去买定位 B的产品然后抱怨不好用。比如拿 Dots 去做单轮快问快答会觉得它慢、步骤多、还要配置拿 Grok Bot 去跑十步以上的长流程会发现它在第三步就开始丢上下文。这不是产品的问题是选型时没先把任务形态描述清楚。我的建议是动手前先用一句话写下你的任务我要在 X 分钟内用 Y 个数据源产出 Z 形态的结果中间是否需要人审。这句话写不出来选什么都会后悔。1.2 为什么开放范围比能力清单更决定长期成本功能清单是静态的开放范围是动态的。今天少一个工具明天官方补上就行但开放范围决定了你能不能自己补、补完之后能不能带走、带不走的话迁移成本有多高。我把这类成本归成三类锁定选型时一定要逐条问清楚。锁定类型具体表现后果提前验证的方法工具锁定只能用官方内置工具无法接入自有系统关键一步永远要人工搬数据问能否注册自定义函数或接入标准工具协议数据锁定会话、记忆、素材无法批量导出换平台等于从零开始问有无导出接口导出格式是否结构化流程锁定编排逻辑只能在平台内可视化编辑无法版本化无法做灰度、回滚、代码评审问编排定义能否导出为文本并纳入版本管理这三类里最容易被忽略的是流程锁定。工具和数据大家都会问编排逻辑的锁定很多人等到要接第二个团队、要做变更评审的时候才发现——所有流程都躺在某个后台里谁改了什么没人说得清。我在一个模拟项目里就吃过这个亏一套每天早上跑的日报流程改了一个筛选条件两周后才发现某个分支被静默跳过因为编排定义没有版本、没有 diff、没有回滚。后来我们把所有编排定义强制导出成 YAML 放进代码仓库这个问题才彻底消失。反过来说开放范围大的代价是配置成本高。Dots 这类编排型代理第一次上手要花半天到一天把工具、凭证、人审节点理顺比打开聊天框就说话要麻烦得多。但这个投入是一次性的而且会随着任务数量增加被摊薄。判断标准很简单这个任务你会做一次还是做一百次。做一次选开箱即用的做一百次选开放范围大的哪怕第一次配置麻烦。1.3 能力边界的三条判定线抛开功能清单我判断一个 AI 代理的能力边界只看三条线这三条线基本能框住 90% 的实际问题。第一条是工具调用深度也就是它能不能连续多轮调用工具、中间结果能不能被下一步正确引用。单轮调用查一次、答一次现在基本都能做难的是五步以上、且后一步依赖前一步返回结构的链式调用。链一长参数幻觉、字段名漂移、超时重试这些问题就会冒出来。第二条是上下文持久化层级。会话内记忆、跨会话记忆、项目级记忆是三件完全不同的事。会话内记忆是基础跨会话记忆要求它能判断什么该记、什么不该记很容易串味项目级记忆要求记忆可以被隔离、被检索、被清理。Grok Bot 偏向前两者Muse 在长上下文和素材库上更强Dots 更强调把记忆挂到具体流程节点上。第三条是执行沙箱的形态。完全不执行、云端容器执行、本地环境执行对应的风险和能力完全不同。不执行最安全但只能产出文本云端容器能跑代码但要考虑数据出境本地执行能力最强但要自己承担权限风险。这条线经常被忽略直到某天你需要它真的把文件改掉而不是告诉你怎么改。2. 能力边界拆解三款代理各自能做什么、不能做什么2.1 Grok Bot实时信息流驱动的高频短任务选手Grok Bot 的强项非常明确——它把当下这件事做得很好。信息检索链路短、响应快对时效性内容行情波动、突发消息、社交平台上的即时讨论的抓取和归纳是同价位里比较顺手的。我日常用它最多的场景是三类一是快速确认某个说法在当下是否成立二是把一堆零散链接压成一段可读摘要三是给一个初步判断然后再决定要不要深挖。它的能力边界也很清楚。第一长文档处理不是它的主场超过一定长度的材料丢进去细节召回会明显下降尤其是需要精确引用原文句子的场合。第二多步工具链的稳定性一般超过五六步的流程中间环节失败后的恢复策略比较粗糙经常是整条重跑而不是从断点续。第三对本地文件系统和自有系统的写入能力弱它更擅长读世界不擅长改你的系统。注意把 Grok Bot 当成信息前置过滤器用效率最高把它当成流程执行器用失望最大。这个定位搞反了评价就会失真。我在一个模拟项目里做过对比同样一条整理某话题过去 24 小时的关键讨论的任务Grok Bot 平均两分半出结果信息新鲜度明显领先但当我要求把结果按固定模板写进本地某个目录并生成索引时它只能给我一段文本让我自己粘链路就断了。这不是缺陷是它本来就没打算做这件事。2.2 Muse长内容与多模态创作型代理Muse 的定位更接近工作室。它的长上下文承载能力、素材组织方式、以及对风格一致性的控制是我在三个里最愿意用来做交付物的。具体表现是给它一份长篇材料它能保持结构不散给它一组参考素材它能在后续产出里维持统一的语气和视觉调性它对改第三段但别动别的这类精确指令的服从度也更高。边界同样明显。一是实时性弱它不擅长回答现在怎么样更适合回答这些材料说明了什么。二是对外部系统的写入能力有限它的产出更多停留在文档、素材、结构化文本层面要真正落到业务系统里通常还需要一层胶水。三是长上下文不等于无损上下文材料越长中段的细节越容易被概括掉我一般会把关键约束写在开头和结尾各一遍中间再用小标题切分召回率会好不少。这里有个实操心得值得单独说用 Muse 做长文时不要一次性把要求全塞进去。我的做法是先让它输出一份大纲并锁定再逐节展开每节展开时只带相关材料片段。这样做的原因很实在——一次性塞满模型在做全局规划时会把注意力摊薄越到后面越容易跑偏分节推进相当于人为给它做了注意力聚焦代价是多几轮交互换来的是返工率大幅下降。2.3 Dots面向工作流的编排型代理Dots 的核心不是聪明是有条理。它把任务拆成节点节点之间可以有条件分支、循环、人审卡点、失败重试还能挂定时触发。这类代理的价值在重复性流程上体现得最充分每天早上八点拉数据、清洗、生成日报、等人确认、发出去全程只需要在异常时介入。它的边界在于单点能力不突出。同样一个单步任务Dots 往往比另外两个慢因为要走完整的节点调度。学习曲线也是三者里最陡的第一次配置要理解节点、变量、作用域、凭证管理这一套概念。我见过不少人第一天就放弃原因是拿它去做一件本该一句话搞定的事。但只要你手上的任务满足重复 多步 需要留痕这三个条件Dots 的优势就会指数级放大。我做过一个粗略统计一个五步流程手工做一次约 25 分钟用它跑稳定后人工介入时间降到 3 分钟以内而且每一步的输入输出都有记录出问题能定位到具体节点。这种可追溯性是聊天式代理给不了的。2.4 三者能力边界对照下面这张表是我自己选型时用的版本维度是按会不会在实际使用中卡住我筛的不是官方参数表。维度Grok BotMuseDots时效性信息获取强链路短弱偏离线材料中取决于挂的数据源单次任务可承载时长短分钟级中长十分钟级以上长可跨小时跨天多步工具链稳定性中五六步后易断中偏读写不偏调度强节点级重试长文档细节召回一般强中多模态产出弱到中强弱通常调外部工具对外部系统写入弱弱到中强可挂各类连接器人审卡点无原生支持无原生支持原生支持上手成本低几乎为零低到中中到高适合的任务密度高频短任务低频重交付固定节奏的重复流程看完这张表你会发现三个产品其实不构成直接竞争关系它们覆盖的是任务光谱上的不同段。真正的选型问题不是哪个更强而是我的任务落在哪一段以及未来半年会不会迁移到另一段。3. 开放范围解析插件、协议、数据出口与二次开发3.1 工具接入的三条路径差别比想象中大AI 代理能不能干活八成取决于工具接入。目前主流就三条路径内置工具、插件市场、标准协议接入。三款代理在这条路上的开放程度差异明显而这个差异会直接决定你能不能让代理碰到自己的业务系统。内置工具最省事但天花板最低官方没做的你只能等。插件市场是中间态生态丰富度决定可用性但质量参差涉及数据出境的插件要格外谨慎。标准协议接入是开放度最高的一条本质是把你的能力描述成一份结构化清单交给代理代理按需调用。下面是一份最小可用的工具描述示例三款代理对这类结构的支持程度不同但思路是通的。{ name: query_internal_metrics, description: 查询内部指标库返回指定指标在时间区间内的按日聚合值。仅用于只读查询。, parameters: { type: object, properties: { metric_key: { type: string, description: 指标标识如 daily_active_users }, start_date: { type: string, description: 起始日期格式 YYYY-MM-DD }, end_date: { type: string, description: 结束日期格式 YYYY-MM-DD }, granularity: { type: string, enum: [day, week], default: day } }, required: [metric_key, start_date, end_date] } }写好这份描述有几个细节值得强调。description 一定要写清什么时候该用、什么时候不该用因为代理选工具靠的就是这段自然语言写含糊了它就会乱调。参数里凡是枚举值务必用 enum 穷举否则模型很容易自由发挥出一个不存在的取值。涉及写操作的接口把仅用于只读查询这类约束写在描述里能在一定程度上减少误调用但不能完全依赖它——真正的防线是权限。Grok Bot 在这条路上偏保守可接入的外部能力有限好处是踩坑概率低Muse 更开放一些但重心在素材与内容侧Dots 的开放度最高连接器和自定义工具的注册都比较完整代价是你要自己管好凭证和作用域。我的经验是先用最小权限把链路跑通再逐步放开千万别一上来就给全权限的密钥。3.2 数据出口与记忆可迁移性这一块是最容易被低估的。你在一个平台上跑了三个月积累了大量会话、记忆、素材、编排定义这些到底算谁的、能不能带走、带走之后能不能用直接决定了你被锁定的程度。我的做法是做一个月度导出的例行动作不管用哪个平台都执行。导出的内容分四类会话归档、记忆条目、素材文件、编排定义。会话归档和素材文件一般都有导出入口记忆条目要看平台是否提供结构化接口编排定义最考验开放度能导出成文本的才算真正可迁移。下面这段是我常用的导出脚本骨架重点是先把结构摸清楚再批量拉。import json, time, pathlib OUT pathlib.Path(./agent_backup) OUT.mkdir(exist_okTrue) def dump_sessions(client, page_size50): cursor None idx 0 while True: resp client.list_sessions(cursorcursor, limitpage_size) for s in resp[items]: path OUT / fsession_{idx:05d}.json path.write_text(json.dumps(s, ensure_asciiFalse, indent2), encodingutf-8) idx 1 cursor resp.get(next_cursor) if not cursor: break time.sleep(0.3) # 温和限速避免触发流控 return idx def dump_memory(client): items client.list_memory_entries() (OUT / memory.jsonl).write_text( \n.join(json.dumps(m, ensure_asciiFalse) for m in items), encodingutf-8, ) return len(items)这段代码没什么技术含量关键在于那个time.sleep(0.3)。我踩过的坑是批量拉取时没有限速跑到一半被流控挡回来前功尽弃。另外要注意导出内容里可能包含凭证或个人信息落盘前最好过一遍脱敏别把备份目录直接扔进公共仓库。三款代理在这个维度上的差别我这么总结Grok Bot 的会话导出最直接但记忆条目偏黑盒能看不能精细改Muse 的素材与文档导出体验最好适合内容型团队Dots 的编排定义可导出程度最高适合需要走代码评审流程的团队。判断方法很简单你就问一句如果明天要换平台我需要几天答案超过三天的就要认真考虑是不是要提前做迁移预案。3.3 权限模型与审计能力开放范围越大权限模型的重要性越高。一个能调你内部系统、能写文件、能发消息的代理如果权限是一把全能的钥匙那它出错的代价就是灾难性的。我看权限只看三件事作用域是否可细分、凭证是否能轮换、操作是否留痕。作用域细分的意思是能不能做到这个代理只能读这张表不能读别的。做得到就按最小权限给做不到就得靠外部网关兜一层。凭证轮换是指密钥能不能定期换、换了之后流程不用改。留痕是指每一次工具调用有没有记录输入输出、谁触发的、耗时多少。第三点在排查问题时价值极高我遇到过代理把一个日期参数理解错、连续跑了七次的情况正是因为每次调用都有记录五分钟就定位到了。提示给代理配权限时先把它能造成的最大破坏写下来再看这个破坏你能不能接受。接受不了就收窄权限而不是指望提示词约束它。Dots 在这方面的原生支持最完整节点级的人审卡点和调用日志基本开箱可用Muse 的权限相对粗放更依赖账号体系Grok Bot 因为外部写入能力本来就弱风险敞口反而小。这个结论有点反直觉——能力最弱的那个风险往往最低。安全性和能力从来都是一体两面别只盯着能力看。3.4 二次开发友好度从改提示词到写代码二次开发这件事门槛分三层。第一层是改提示词和知识库三款都能做第二层是注册自定义工具、写连接器Grok Bot 受限较多Muse 中等Dots 最开放第三层是把代理当成一个可编程组件嵌进自己的系统这一层要看有没有稳定的接口、能不能拿到结构化的中间状态。第三层是我最看重的。理由很实在代理再强也很难独立承担端到端业务它一定是嵌在某个系统里的一环。这一环的输入输出如果都是自然语言那上下游都得靠人去粘自动化程度上不去如果中间状态是结构化的你就能做校验、做重试、做灰度。下面是一个调用侧的简单封装重点是超时和重试策略不要裸调。# 调用代理执行一个结构化任务带超时与重试 for i in 1 2 3; do resp$(curl -sS --max-time 120 \ -H Content-Type: application/json \ -H Authorization: Bearer ${AGENT_TOKEN} \ -d task_payload.json \ ${AGENT_ENDPOINT}/v1/runs) if [ $? -eq 0 ] echo $resp | grep -q status:succeeded; then echo $resp result.json break fi echo attempt ${i} failed, retrying... 2 sleep $((i * 5)) done这段脚本没什么花活但三个细节决定了它在生产里能不能用--max-time必须设代理类接口的响应时间方差很大不设超时会挂住整个流程重试要退避别原地狂刷成功判定要用结构化字段别去匹配自然语言内容因为模型的措辞是会变的。最后这条我吃过亏早期用关键词匹配判断成功结果模型换了个同义表达整条链路就一直认为失败白跑了半小时。4. 实操把同一件事分别交给三款代理跑一遍4.1 任务设定与验收标准光讲定位没意思得有一件具体的活。我设计的任务是一件很常见的事——做一份竞品周报包含四个环节抓取指定几个公开渠道过去七天的更新、做去重和要点归纳、按固定模板生成一份周报文档、走一次人工确认后再归档。选这个任务的原因是它同时覆盖了时效抓取、长内容组织、流程编排三块正好把三款代理的边界都逼出来。验收标准我定了五条都能量化避免感觉还行这种模糊判断。验收项标准为什么定这条完整度四个环节全部完成无人工补做检验端到端能力而非单点能力事实准确关键信息可回溯到原始来源代理最容易在归纳环节编造细节结构合规输出符合模板字段可直接入库检验结构化输出稳定性人工介入除确认环节外干预次数不超过 2 次检验自主性总耗时从触发到归档检验实际效率不是纸面速度注意验收标准一定要在跑之前定好跑完再定标准人会不自觉地往它做到了什么上靠评估就失真了。4.2 分步实录三款代理的实际表现先说 Grok Bot。触发之后它的信息抓取环节跑得最快一上来就把几个渠道的更新捞全了去重和要点归纳也基本可用。问题出在第三步要求它按固定模板生成文档并落到指定位置时它给了一份结构还算规整的文本但没有真正写入需要我手动粘贴。人工介入两次一次是补做写入一次是修正两个日期表述。总耗时约十二分钟其中人工占了七分钟。结论很清楚它适合当周报的前半段引擎不适合当整条流水线。再说 Muse。它的表现分化得很明显。归纳环节质量最高同一批材料它给出的要点层次更清楚、重复信息合并得更干净长文档输出的结构也最稳定模板字段基本一次到位。但抓取环节弱几个渠道的更新它拿不全需要我把材料先喂进去。人工介入三次主要花在补材料和调整一段措辞上。总耗时约二十五分钟但其中真正的人工只有五分钟其余是它自己在写。这个时间结构很关键——它慢但不是慢在等人。最后是 Dots。第一次配置花了将近四十分钟把抓取连接器、清洗节点、生成节点、人审卡点、归档节点逐个接起来中间调试了两次变量作用域。配好之后跑第一遍抓取和清洗顺利生成环节因为一个字段名对不上失败了日志直接指到具体节点和具体字段改完重跑就通了。人工介入两次都在配置阶段运行阶段只有人审那一次确认。总耗时首跑约十八分钟第二周再跑只用了六分钟而且我全程没盯着。把三次结果放在一起最有意思的发现不是谁快谁慢而是人工时间的分布完全不同。Grok Bot 的人工在事后补救Muse 的人工在前置准备Dots 的人工在一次性配置。选型时真正该问的是你更愿意把时间花在哪一段如果你团队里没人愿意做前置准备Muse 的高质量产出你也拿不到如果你讨厌事后补救那 Grok Bot 每次都会让你烦。4.3 选型矩阵按任务形态而不是按产品选跑完这一轮我整理了一张按任务形态选型的矩阵比按产品对比更有用。你的任务形态首选理由需要注意每天几十次快速查证、短回复Grok Bot链路短、时效强别指望它写文件交付长文档、多模态素材Muse长上下文与风格一致性好材料要自己备齐固定节奏的重复多步流程Dots节点级控制与留痕首次配置要有耐心一次性调研 人工整理Grok Bot Muse前者抓、后者写中间要人工转一次需要人审的对外流程Dots原生人审卡点卡点别设太多会拖慢探索性、目标不明确的任务Muse发散能力强要频繁收敛否则跑偏这张表我最常用的是最后两行。需要人审的对外流程这条很多团队一开始设了五六个卡点结果流程比手工还慢后来砍到只剩一个关键卡点效率立刻回来了。人审的目的是兜住不可逆的操作不是把每一步都变成审批。5. 常见问题与排查技巧实录5.1 工具调用失败的四类典型症状工具调用出问题症状看着都差不多——它没做成但根因完全不同。我把踩过的坑归成四类按出现频率排序。第一类是参数幻觉代理调用工具时填了一个不存在的参数值比如日期格式写成上周、指标名写成自然语言。根因通常是工具描述里的枚举没穷举或者描述写得太模糊。解决办法是把 enum 写全并在描述里给出一到两个正例。第二类是超时与重试风暴一次调用超时后代理连着重试七八次把配额打光。根因是重试策略没设上限和退避。解决办法是在工具侧限制重试次数同时在编排层做幂等避免重复写入。第三类是权限拒绝返回 403 或类似错误。这类最好排查看作用域配置就行。但要注意一种隐蔽情况权限本身没问题是凭证过期了而错误信息被包装成了工具不可用看起来像功能问题。第四类是返回结构漂移工具返回的字段名或层级和你预期不一致代理解析失败。这类最难查因为有时候成功有时候失败。根因往往是上游接口做了不兼容变更。我的做法是在调用侧加一层结构校验字段对不上就明确报错而不是让代理去猜。5.2 记忆串味与上下文污染跨会话记忆是个双刃剑。用得好代理记得你的偏好、你的项目背景省掉大量重复交代用不好上一件事的约束会污染下一件事。我遇到过最典型的一次前一个任务要求语气尽量简洁这个偏好被记进了长期记忆结果后面写正式文档时也被压得极简返工了三轮才发现是记忆在作祟。排查思路是分层排查。先确认是会话内上下文污染还是跨会话记忆污染——开一个新会话重跑如果问题消失就是会话内的如果还在就是跨会话的。然后再看是偏好类记忆还是事实类记忆。偏好类记忆最容易串味因为它天然是全局的事实类记忆相对安全但也可能过期。处理办法有三条我在实际项目里都用过。一是给不同任务划分独立的记忆作用域别让所有任务共享一个池子二是对关键约束采用就地声明每次任务开始明确写一遍不完全依赖记忆三是定期清理我一般每个月过一遍记忆条目把过期的项目背景删掉。第三条听起来麻烦但比起被一条过期记忆坑一下午这点时间花得值。5.3 成本失控的三条排查路径代理类产品的成本结构和聊天式产品不一样它按步骤烧钱一个任务可能触发十几次模型调用加十几次工具调用。成本突然翻倍通常不是单价涨了是步骤变多了。第一条路径看循环。编排里最容易出问题的是循环条件写得过宽导致本该三次结束的循环跑了三十次。排查方法是看单次任务的调用次数分布有没有明显的长尾。第二条路径看上下文膨胀。每一步都把全部历史塞进去token 会指数级增长。解决办法是在节点之间只传必要字段长材料用引用而不是全文透传。这一条优化下来我在一个模拟项目里把单任务成本压到了原来的四成左右。第三条路径看失败重试。失败的重试也是要花钱的而且经常是同一个错误反复重试。解决办法前面说过限制次数、加退避、做幂等。5.4 排查速查表症状最可能的原因快速验证处理代理说做了但其实没做只有文本产出无写入能力检查是否有写入类工具补工具或换编排型代理中途停止无报错上下文超限或超时缩短任务、分段跑拆任务、加检查点同一操作重复多次重试策略无上限看调用日志次数限次 幂等输出格式每次不一样模板约束不够硬对比三次输出结构用结构化输出 校验记得不该记的东西记忆作用域未隔离新会话重跑划分作用域、定期清理成本突然翻倍循环过宽或上下文膨胀看单任务调用次数分布精简传参、收紧循环6. 我自己的搭配方式与几点体会跑了这么多轮我现在的做法是三款并用但分工非常明确。Grok Bot 当前置雷达所有需要确认当下发生了什么的事都先过它一遍成本低、速度快判断错了损失也小。Muse 当交付车间确定要出正式东西的时候才切过去把材料备齐、把约束写清让它专心做长内容。Dots 当值班员凡是每周固定要跑、且需要留痕的流程全部搬进去配好之后基本不用管出问题看日志就能定位。这个搭配不是最优解只是在我这种一个人要覆盖调研、产出、运维三件事的场景下最省心。如果你是一个团队分工可以更细如果你只做单一类型的工作完全没必要三个都用选一个把边界摸透收益比换来换去大得多。有三点体会我想单独说。第一先摸边界再谈优化。很多人一上来就想让代理做更多结果是在边界外反复碰壁浪费时间。花半天时间把它在哪一步会断搞清楚后面所有设计都会顺很多。第二结构化输入输出是自动化程度的分水岭。只要中间环节还是自然语言你就永远需要人在中间粘一旦能拿到结构化状态校验、重试、灰度这些工程手段才用得上。第三别用提示词去约束本该用权限约束的事。提示词是软的权限是硬的涉及不可逆操作时一定要在权限层兜住而不是写一句请不要删除重要文件然后祈祷它听话。最后分享一个小技巧对三款代理都适用给每个任务加一个自检步骤让它在结束前用三句话回答——做了什么、依据是什么、哪一步不确定。这三句话在排查问题时价值极高尤其是哪一步不确定这一条经常能提前暴露我根本没注意到的隐患。成本只多一次短调用省下的排查时间往往以小时计。