1. 从写提示词到交钥匙一个正在发生的转折过去两年我身边做 AI 应用的朋友几乎都在干同一件事——调提示词。为了让模型输出稳定有人把系统提示写成三千字的小作文有人给每个字段加三遍约束还有人专门维护一份咒语库把踩过的坑一条条记下来。这套方法在 GPT-4 时代确实管用因为那时候模型的理解力有限你不把话说死它就给你自由发挥。但 GPT-6 这一代模型出来之后我明显感觉到一个变化提示词工程的天花板正在快速下降。不是它不重要了而是它的边际收益在急剧衰减。你花三天打磨的提示词可能只比一句大白话多出 5% 的准确率提升。与此同时模型对意图的理解能力、对工具调用的自主性、对多步任务的规划能力都在肉眼可见地变强。这就引出一个很多人还没反应过来的问题当模型足够聪明的时候你该做的不是继续教它怎么做而是学会放手让它自己做。标题里说的对 AI 放手不是躺平不管而是一种能力升级——从操作员变成委托人。操作员关心的是每一步怎么走委托人关心的是目标是什么、边界在哪里、结果怎么验收。这个转变听起来简单但真正做起来涉及提示词策略、Agent 架构、工具权限、并发控制、成本管理一整条链路的重构。这篇内容我打算把这条链路拆开讲清楚。适合两类人看一类是已经在用 AI 做实际项目、但感觉越用越累的开发者另一类是刚接触 AI Agent、想知道放手到底怎么放、放到什么程度才安全的新手。我会结合 Computer Use、Codex 这类具体形态讲清楚哪些环节可以放手、哪些必须留手、以及放手之后怎么保证不出事。2. 提示词工程的黄昏为什么把话说死越来越不划算2.1 提示词的本质是在补偿模型的能力缺口先想清楚一件事提示词工程为什么曾经那么重要本质上提示词是在用自然语言给模型打补丁。模型不知道你的业务规则你就在提示里写清楚模型容易跑偏你就加约束模型输出格式不稳定你就给示例。每一条提示词都是在填补模型能力和你需求之间的那道缝。GPT-4 时代这道缝很宽。你让它做个数据提取它可能给你返回一段散文你让它调用工具它可能把参数编错。所以那时候的提示词写得像法律合同恨不得把每种情况都枚举一遍。但 GPT-6 这一代缝在变窄。模型对模糊指令的容忍度高了对工具 schema 的理解准了对多轮上下文的记忆也稳了。这时候你再用老办法写提示词就会出现一个尴尬局面你写的约束越多模型反而越束手束脚。它会因为过度遵守某条规则而放弃更合理的解法。我实测过一个场景让模型从一段客服对话里提取用户诉求、情绪、紧急程度三个字段。老写法是给每个字段写定义、给边界条件、给三个 few-shot 示例提示词接近八百字。新写法只有一句读这段对话判断用户想要什么、情绪如何、急不急用 JSON 返回。结果新写法在准确率上只低了不到 2 个百分点但响应速度快了将近三成token 消耗少了一半。2.2 过度提示的三种典型反噬很多人没意识到提示词写太多是有代价的。我总结下来有三种反噬第一种是注意力稀释。模型的上下文窗口虽然大但注意力是有限的。你塞进去三千字规则真正关键的那句如果信息缺失就返回 null可能就被淹没了。模型不是没看到而是权重被摊薄了。第二种是规则冲突。提示词写多了难免出现互相打架的条款。比如你既要求输出必须简洁又要求必须覆盖所有边界情况模型就得自己权衡权衡的结果往往不可预测。第三种是维护成本爆炸。一份两千字的系统提示改一个字段可能牵动三处逻辑。团队里换个人接手光读懂提示词就要半天。这已经不是工程是考古。2.3 那提示词还要不要写要写但写的东西变了。以前写的是怎么做现在写的是做什么和不能做什么。具体来说我现在的提示词结构大概是三层目标层一句话说清楚任务是什么、成功标准是什么。边界层哪些事绝对不能做比如不能编造数据、不能越权调用、不能泄露敏感信息。格式层只在输出需要被程序解析时才规定格式其余情况让模型自己组织。至于中间那些先做 A 再做 B 再做 C的步骤我基本不写了。因为模型自己规划得比我好我写死步骤反而限制了它的发挥。提示如果你现在的提示词超过一千字先别急着优化试着砍掉一半看看效果是变好还是变差。我赌大概率不会变差。3. 放手的第一层把步骤控制交给 Agent 规划3.1 从 Chain 到 Agent 的思维切换早期做 AI 应用主流是 Chain 模式——你把任务拆成固定步骤A 的输出喂给 BB 的输出喂给 C。这套东西可控、可调试但有个致命问题步骤是写死的任务一变就得重写。Agent 模式不一样。你给它一个目标它自己决定用哪些工具、按什么顺序、走几步。这就像你以前是手把手教实习生干活现在改成给他一个 KPI 让他自己想办法。GPT-6 这一代模型做规划的能力已经跨过了能用的门槛。我拿一个真实任务测过给一份杂乱的会议录音转写稿要求整理出待办事项、负责人、截止时间并写入表格。Chain 模式需要我先做说话人分离、再做要点提取、再做字段映射三步三个提示词。Agent 模式只给一句目标模型自己决定先通读、再识别行动项、再抽取字段、最后调用写表工具中间还会自己检查有没有遗漏。结果 Agent 模式在完整度上明显更好因为它会回头看一眼而 Chain 模式是单向流水线过了就过了。3.2 规划能力到底强在哪模型自主规划的价值体现在三个地方一是动态调整。任务执行到一半发现信息不够Agent 会自己去补而不是卡在那里。比如提取待办时发现某条没写负责人它会回到原文找上下文找不到才标记为待定。二是工具选择。你给它一堆工具它自己判断该用哪个。查数据用搜索、算数用计算器、写文件用文件工具不用你写 if-else 去路由。三是错误恢复。调用工具失败了它会换个方式重试而不是直接报错退出。这一点在真实环境里特别重要因为外部 API 抖动是常态。3.3 放手不等于放任规划也要有护栏但我要泼一盆冷水Agent 自主规划不是没有代价的。最大的风险是它可能走进死循环或者调用你不想让它调用的工具。所以放手的前提是设好护栏。我的做法是步数上限给 Agent 设一个最大迭代次数比如 15 步超了就强制停止并返回当前结果。工具白名单只暴露当前任务需要的工具不要把所有工具都挂上去。关键动作确认涉及写操作、删除操作、对外发送的操作必须经过确认或走审批流。这三条护栏设好之后Agent 的自主性就可以放得比较开。我现在的项目里读操作基本全放写操作走确认删除操作一律禁止自动执行。4. 放手的第二层Computer Use 让 AI 真正下地干活4.1 为什么 Computer Use 是分水岭如果说 Agent 规划是让 AI 会想那 Computer Use 就是让 AI 会做。以前的 AI 应用能力边界卡在 API 上——有 API 的能调没 API 的干瞪眼。但现实世界里大量系统根本没有 API或者 API 残缺不全。你想让 AI 帮你操作一个老后台、填一个网页表单、导出一份报表传统方案要么写爬虫要么人工代劳。Computer Use 把这条路打通了。模型直接看屏幕、动鼠标、敲键盘像人一样操作界面。这意味着AI 的能力边界从有 API 的系统扩展到了所有能看见的界面。我拿 Codex 这类命令行 Agent 试过让它自己读代码、改代码、跑测试、看报错、再改整个循环不需要人插手。这种感知-行动-反馈的闭环才是真正意义上的自动化。4.2 放手操作界面的三个现实约束但 Computer Use 现在还没到可以完全撒手的程度有三个约束你得心里有数第一是速度。看屏幕、定位元素、点击这套流程比调 API 慢一个数量级。适合做低频、复杂、非实时的任务不适合高频批量操作。第二是稳定性。界面稍微变个布局模型可能就找不到按钮了。所以关键流程要加视觉锚点或者用更稳的定位方式。第三是权限。让 AI 操作你的电脑等于把钥匙交出去。必须做权限隔离比如跑在沙箱环境、用独立账号、限制可访问的目录和网站。我的经验是Computer Use 适合做最后一公里的补位也就是那些没有 API、但又不值得专门开发的场景。核心链路还是尽量走 API稳定性和速度都更好。4.3 一个真实的放手案例我帮一个朋友做过一个自动化流程每天从三个不同的后台系统导出数据合并后生成日报。这三个系统里一个有小程序接口一个只有网页后台一个是桌面客户端。传统做法是写三个脚本维护成本极高。用 Computer Use 的方案是让 Agent 分别操作这三个界面导出文件到指定目录然后统一处理。整个过程人只需要在开始时点一下开始结束时看一眼结果。实测下来稳定性大概在 90% 左右偶尔会因为界面加载慢而失败加个重试就解决了。这个方案的价值不在于多快而在于把一件需要人每天花二十分钟的琐事变成了完全不用管的背景任务。5. 放手的第三层并发与成本放手之后的新战场5.1 Agent 并发为什么比 API 并发难很多人以为 Agent 并发就是多开几个请求其实完全不是一回事。普通 API 调用是无状态的来一个请求处理一个互不干扰。但 Agent 是有状态的它有自己的上下文、自己的工具调用序列、自己的中间结果。多个 Agent 同时跑会争抢资源、互相污染上下文、甚至触发同一份数据的并发写。我踩过的一个坑同时跑五个 Agent 处理同一批文件结果有两个 Agent 读到了对方正在写的中间文件输出全乱了。后来加了任务队列和文件锁才解决。所以 Agent 并发的核心不是开多少而是怎么隔离。我的做法是任务级隔离每个 Agent 一个独立的工作目录互不交叉。资源级限流对共享资源数据库、外部 API做统一限流避免打爆。状态级快照关键节点存快照出问题能回滚。5.2 Token 成本放手之后最容易失控的地方Agent 自主性越强token 消耗越不可预测。因为它会自己决定走几步、调几次工具、读多少上下文。我见过一个案例一个 Agent 因为没找到目标信息反复搜索了四十多次单次任务烧掉了正常情况二十倍的 token。这不是模型笨是它太执着。控制成本的手段有几个手段作用我的实际效果步数上限防止无限循环成本波动从 20 倍降到 3 倍以内上下文裁剪减少无效历史单次 token 降约 40%结果缓存避免重复计算重复任务成本降 80% 以上模型分级简单任务用轻量模型整体成本降约一半其中模型分级我觉得最值得做。不是所有步骤都需要最强模型规划用强的执行用快的能省很多。5.3 并发和成本的平衡点放手之后你要在让 Agent 自己跑和控制资源消耗之间找平衡。我的经验值是单个 Agent 任务的 token 预算设成预期值的 3 倍作为上限。超过就中断人工介入看看是哪里出了问题。这个阈值既能容纳正常的探索开销又能拦住失控的情况。并发数则取决于你的下游资源。如果 Agent 要调外部 API并发数不能超过对方的限流如果只是本地处理可以按 CPU 和内存来定。我一般从 3 到 5 个并发起步观察稳定后再往上加。6. 放手的边界哪些事永远不能交给 AI 自己决定6.1 三类必须留手的操作放手是有底线的。我总结了三类操作无论模型多强都不能完全交给它自己决定第一类是破坏性操作。删除数据、覆盖文件、清空表这类操作一旦做错无法挽回。必须走确认流程或者至少保留可恢复的备份。第二类是对外承诺。给客户发消息、提交订单、签署协议这类操作代表的是你的信誉。AI 可以起草但发送前必须有人过目。第三类是涉及资金和权限的操作。转账、授权、改密码这些必须有人工确认环节。不是不信任模型是这类操作的容错率太低。6.2 怎么设计人在环中的确认机制确认机制设计得好不好直接决定放手体验。设计得差你会被确认弹窗烦死设计得好你几乎感觉不到它的存在。我的做法是分级确认低风险自动执行事后记录日志。中风险执行前弹一次确认可以批量确认。高风险执行前确认且需要二次验证。关键是把确认做在关键节点上而不是每一步。比如一个 Agent 要改十个文件不需要改一个确认一次而是在它列出改动清单后确认一次。6.3 放手之后怎么验收放手不等于不看结果。验收环节反而更重要因为过程你不管了结果必须管住。我的验收习惯是三个问题结果对不对核心指标有没有达标。过程有没有越界有没有调用不该调的工具、访问不该访问的数据。成本合不合理token 和时间消耗在不在预期内。这三个问题对应三份日志结果日志、操作日志、成本日志。有了这三份日志放手才放得安心。7. 从操作员到委托人心态和技能的双重转变7.1 你不再是写指令的人而是定标准的人放手最大的障碍不是技术是心态。很多人习惯了我说一步它做一步的掌控感一旦让 AI 自己规划就浑身不自在总想插手。这种心态在 GPT-4 时代是必要的在 GPT-6 时代是拖累。你要接受一个事实在具体执行上模型可能比你更懂怎么走。你的价值不在于告诉它每一步怎么走而在于告诉它什么叫做得好、什么叫做不能碰。这就像带团队。好的管理者不会盯着每个人怎么敲键盘而是把目标、标准、边界说清楚然后让团队自己想办法。7.2 需要补的新技能放手之后有几项技能变得更重要第一是任务分解的颗粒度把控。拆得太细等于没放手拆得太粗Agent 容易跑偏。我的经验是拆到一个可验收的成果这个粒度比如整理出待办清单是一个任务把清单写进表格是另一个任务。第二是工具设计。Agent 的能力上限取决于你给它的工具。工具设计得好Agent 如虎添翼设计得差Agent 寸步难行。工具要原子化、语义清晰、错误信息友好。第三是评估体系。放手之后你怎么知道 Agent 干得好不好必须有自动化的评估。我一般会准备一批标准测试用例每次改完 Agent 配置就跑一遍看通过率有没有下降。7.3 一个判断标准你是在教它做事还是在告诉它要什么最后分享一个我自己的判断标准。每次写提示词或者配 Agent 的时候我会问自己一句我现在是在教它做事还是在告诉它要什么如果发现自己在写第一步做 A第二步做 B那就是在教它做事说明我还没放手。如果写的是目标是 X不能碰 Y做完给我看 Z那就是在告诉它要什么这才是放手的状态。这个标准帮我砍掉了大量不必要的提示词也让我从调提示词调到吐的状态里解脱出来。说到底GPT-6 最大的变化不是它变聪明了多少而是它终于聪明到值得你信任它自己去做。提示词工程不会消失但它的重心会从控制转向委托。学会放手不是偷懒是把你的精力从执行细节里抽出来放到真正需要人判断的地方——目标、边界、验收。我在实际项目里的体会是放手初期会有一段不适应期总觉得不踏实。但一旦护栏设好、验收跑通你会发现 Agent 能扛的事比你想象的多得多。真正难的从来不是让 AI 干活而是你敢不敢让它自己干。
1. 从写提示词到交钥匙一个正在发生的转折过去两年我身边做 AI 应用的朋友几乎都在干同一件事——调提示词。为了让模型输出稳定有人把系统提示写成三千字的小作文有人给每个字段加三遍约束还有人专门维护一份咒语库把踩过的坑一条条记下来。这套方法在 GPT-4 时代确实管用因为那时候模型的理解力有限你不把话说死它就给你自由发挥。但 GPT-6 这一代模型出来之后我明显感觉到一个变化提示词工程的天花板正在快速下降。不是它不重要了而是它的边际收益在急剧衰减。你花三天打磨的提示词可能只比一句大白话多出 5% 的准确率提升。与此同时模型对意图的理解能力、对工具调用的自主性、对多步任务的规划能力都在肉眼可见地变强。这就引出一个很多人还没反应过来的问题当模型足够聪明的时候你该做的不是继续教它怎么做而是学会放手让它自己做。标题里说的对 AI 放手不是躺平不管而是一种能力升级——从操作员变成委托人。操作员关心的是每一步怎么走委托人关心的是目标是什么、边界在哪里、结果怎么验收。这个转变听起来简单但真正做起来涉及提示词策略、Agent 架构、工具权限、并发控制、成本管理一整条链路的重构。这篇内容我打算把这条链路拆开讲清楚。适合两类人看一类是已经在用 AI 做实际项目、但感觉越用越累的开发者另一类是刚接触 AI Agent、想知道放手到底怎么放、放到什么程度才安全的新手。我会结合 Computer Use、Codex 这类具体形态讲清楚哪些环节可以放手、哪些必须留手、以及放手之后怎么保证不出事。2. 提示词工程的黄昏为什么把话说死越来越不划算2.1 提示词的本质是在补偿模型的能力缺口先想清楚一件事提示词工程为什么曾经那么重要本质上提示词是在用自然语言给模型打补丁。模型不知道你的业务规则你就在提示里写清楚模型容易跑偏你就加约束模型输出格式不稳定你就给示例。每一条提示词都是在填补模型能力和你需求之间的那道缝。GPT-4 时代这道缝很宽。你让它做个数据提取它可能给你返回一段散文你让它调用工具它可能把参数编错。所以那时候的提示词写得像法律合同恨不得把每种情况都枚举一遍。但 GPT-6 这一代缝在变窄。模型对模糊指令的容忍度高了对工具 schema 的理解准了对多轮上下文的记忆也稳了。这时候你再用老办法写提示词就会出现一个尴尬局面你写的约束越多模型反而越束手束脚。它会因为过度遵守某条规则而放弃更合理的解法。我实测过一个场景让模型从一段客服对话里提取用户诉求、情绪、紧急程度三个字段。老写法是给每个字段写定义、给边界条件、给三个 few-shot 示例提示词接近八百字。新写法只有一句读这段对话判断用户想要什么、情绪如何、急不急用 JSON 返回。结果新写法在准确率上只低了不到 2 个百分点但响应速度快了将近三成token 消耗少了一半。2.2 过度提示的三种典型反噬很多人没意识到提示词写太多是有代价的。我总结下来有三种反噬第一种是注意力稀释。模型的上下文窗口虽然大但注意力是有限的。你塞进去三千字规则真正关键的那句如果信息缺失就返回 null可能就被淹没了。模型不是没看到而是权重被摊薄了。第二种是规则冲突。提示词写多了难免出现互相打架的条款。比如你既要求输出必须简洁又要求必须覆盖所有边界情况模型就得自己权衡权衡的结果往往不可预测。第三种是维护成本爆炸。一份两千字的系统提示改一个字段可能牵动三处逻辑。团队里换个人接手光读懂提示词就要半天。这已经不是工程是考古。2.3 那提示词还要不要写要写但写的东西变了。以前写的是怎么做现在写的是做什么和不能做什么。具体来说我现在的提示词结构大概是三层目标层一句话说清楚任务是什么、成功标准是什么。边界层哪些事绝对不能做比如不能编造数据、不能越权调用、不能泄露敏感信息。格式层只在输出需要被程序解析时才规定格式其余情况让模型自己组织。至于中间那些先做 A 再做 B 再做 C的步骤我基本不写了。因为模型自己规划得比我好我写死步骤反而限制了它的发挥。提示如果你现在的提示词超过一千字先别急着优化试着砍掉一半看看效果是变好还是变差。我赌大概率不会变差。3. 放手的第一层把步骤控制交给 Agent 规划3.1 从 Chain 到 Agent 的思维切换早期做 AI 应用主流是 Chain 模式——你把任务拆成固定步骤A 的输出喂给 BB 的输出喂给 C。这套东西可控、可调试但有个致命问题步骤是写死的任务一变就得重写。Agent 模式不一样。你给它一个目标它自己决定用哪些工具、按什么顺序、走几步。这就像你以前是手把手教实习生干活现在改成给他一个 KPI 让他自己想办法。GPT-6 这一代模型做规划的能力已经跨过了能用的门槛。我拿一个真实任务测过给一份杂乱的会议录音转写稿要求整理出待办事项、负责人、截止时间并写入表格。Chain 模式需要我先做说话人分离、再做要点提取、再做字段映射三步三个提示词。Agent 模式只给一句目标模型自己决定先通读、再识别行动项、再抽取字段、最后调用写表工具中间还会自己检查有没有遗漏。结果 Agent 模式在完整度上明显更好因为它会回头看一眼而 Chain 模式是单向流水线过了就过了。3.2 规划能力到底强在哪模型自主规划的价值体现在三个地方一是动态调整。任务执行到一半发现信息不够Agent 会自己去补而不是卡在那里。比如提取待办时发现某条没写负责人它会回到原文找上下文找不到才标记为待定。二是工具选择。你给它一堆工具它自己判断该用哪个。查数据用搜索、算数用计算器、写文件用文件工具不用你写 if-else 去路由。三是错误恢复。调用工具失败了它会换个方式重试而不是直接报错退出。这一点在真实环境里特别重要因为外部 API 抖动是常态。3.3 放手不等于放任规划也要有护栏但我要泼一盆冷水Agent 自主规划不是没有代价的。最大的风险是它可能走进死循环或者调用你不想让它调用的工具。所以放手的前提是设好护栏。我的做法是步数上限给 Agent 设一个最大迭代次数比如 15 步超了就强制停止并返回当前结果。工具白名单只暴露当前任务需要的工具不要把所有工具都挂上去。关键动作确认涉及写操作、删除操作、对外发送的操作必须经过确认或走审批流。这三条护栏设好之后Agent 的自主性就可以放得比较开。我现在的项目里读操作基本全放写操作走确认删除操作一律禁止自动执行。4. 放手的第二层Computer Use 让 AI 真正下地干活4.1 为什么 Computer Use 是分水岭如果说 Agent 规划是让 AI 会想那 Computer Use 就是让 AI 会做。以前的 AI 应用能力边界卡在 API 上——有 API 的能调没 API 的干瞪眼。但现实世界里大量系统根本没有 API或者 API 残缺不全。你想让 AI 帮你操作一个老后台、填一个网页表单、导出一份报表传统方案要么写爬虫要么人工代劳。Computer Use 把这条路打通了。模型直接看屏幕、动鼠标、敲键盘像人一样操作界面。这意味着AI 的能力边界从有 API 的系统扩展到了所有能看见的界面。我拿 Codex 这类命令行 Agent 试过让它自己读代码、改代码、跑测试、看报错、再改整个循环不需要人插手。这种感知-行动-反馈的闭环才是真正意义上的自动化。4.2 放手操作界面的三个现实约束但 Computer Use 现在还没到可以完全撒手的程度有三个约束你得心里有数第一是速度。看屏幕、定位元素、点击这套流程比调 API 慢一个数量级。适合做低频、复杂、非实时的任务不适合高频批量操作。第二是稳定性。界面稍微变个布局模型可能就找不到按钮了。所以关键流程要加视觉锚点或者用更稳的定位方式。第三是权限。让 AI 操作你的电脑等于把钥匙交出去。必须做权限隔离比如跑在沙箱环境、用独立账号、限制可访问的目录和网站。我的经验是Computer Use 适合做最后一公里的补位也就是那些没有 API、但又不值得专门开发的场景。核心链路还是尽量走 API稳定性和速度都更好。4.3 一个真实的放手案例我帮一个朋友做过一个自动化流程每天从三个不同的后台系统导出数据合并后生成日报。这三个系统里一个有小程序接口一个只有网页后台一个是桌面客户端。传统做法是写三个脚本维护成本极高。用 Computer Use 的方案是让 Agent 分别操作这三个界面导出文件到指定目录然后统一处理。整个过程人只需要在开始时点一下开始结束时看一眼结果。实测下来稳定性大概在 90% 左右偶尔会因为界面加载慢而失败加个重试就解决了。这个方案的价值不在于多快而在于把一件需要人每天花二十分钟的琐事变成了完全不用管的背景任务。5. 放手的第三层并发与成本放手之后的新战场5.1 Agent 并发为什么比 API 并发难很多人以为 Agent 并发就是多开几个请求其实完全不是一回事。普通 API 调用是无状态的来一个请求处理一个互不干扰。但 Agent 是有状态的它有自己的上下文、自己的工具调用序列、自己的中间结果。多个 Agent 同时跑会争抢资源、互相污染上下文、甚至触发同一份数据的并发写。我踩过的一个坑同时跑五个 Agent 处理同一批文件结果有两个 Agent 读到了对方正在写的中间文件输出全乱了。后来加了任务队列和文件锁才解决。所以 Agent 并发的核心不是开多少而是怎么隔离。我的做法是任务级隔离每个 Agent 一个独立的工作目录互不交叉。资源级限流对共享资源数据库、外部 API做统一限流避免打爆。状态级快照关键节点存快照出问题能回滚。5.2 Token 成本放手之后最容易失控的地方Agent 自主性越强token 消耗越不可预测。因为它会自己决定走几步、调几次工具、读多少上下文。我见过一个案例一个 Agent 因为没找到目标信息反复搜索了四十多次单次任务烧掉了正常情况二十倍的 token。这不是模型笨是它太执着。控制成本的手段有几个手段作用我的实际效果步数上限防止无限循环成本波动从 20 倍降到 3 倍以内上下文裁剪减少无效历史单次 token 降约 40%结果缓存避免重复计算重复任务成本降 80% 以上模型分级简单任务用轻量模型整体成本降约一半其中模型分级我觉得最值得做。不是所有步骤都需要最强模型规划用强的执行用快的能省很多。5.3 并发和成本的平衡点放手之后你要在让 Agent 自己跑和控制资源消耗之间找平衡。我的经验值是单个 Agent 任务的 token 预算设成预期值的 3 倍作为上限。超过就中断人工介入看看是哪里出了问题。这个阈值既能容纳正常的探索开销又能拦住失控的情况。并发数则取决于你的下游资源。如果 Agent 要调外部 API并发数不能超过对方的限流如果只是本地处理可以按 CPU 和内存来定。我一般从 3 到 5 个并发起步观察稳定后再往上加。6. 放手的边界哪些事永远不能交给 AI 自己决定6.1 三类必须留手的操作放手是有底线的。我总结了三类操作无论模型多强都不能完全交给它自己决定第一类是破坏性操作。删除数据、覆盖文件、清空表这类操作一旦做错无法挽回。必须走确认流程或者至少保留可恢复的备份。第二类是对外承诺。给客户发消息、提交订单、签署协议这类操作代表的是你的信誉。AI 可以起草但发送前必须有人过目。第三类是涉及资金和权限的操作。转账、授权、改密码这些必须有人工确认环节。不是不信任模型是这类操作的容错率太低。6.2 怎么设计人在环中的确认机制确认机制设计得好不好直接决定放手体验。设计得差你会被确认弹窗烦死设计得好你几乎感觉不到它的存在。我的做法是分级确认低风险自动执行事后记录日志。中风险执行前弹一次确认可以批量确认。高风险执行前确认且需要二次验证。关键是把确认做在关键节点上而不是每一步。比如一个 Agent 要改十个文件不需要改一个确认一次而是在它列出改动清单后确认一次。6.3 放手之后怎么验收放手不等于不看结果。验收环节反而更重要因为过程你不管了结果必须管住。我的验收习惯是三个问题结果对不对核心指标有没有达标。过程有没有越界有没有调用不该调的工具、访问不该访问的数据。成本合不合理token 和时间消耗在不在预期内。这三个问题对应三份日志结果日志、操作日志、成本日志。有了这三份日志放手才放得安心。7. 从操作员到委托人心态和技能的双重转变7.1 你不再是写指令的人而是定标准的人放手最大的障碍不是技术是心态。很多人习惯了我说一步它做一步的掌控感一旦让 AI 自己规划就浑身不自在总想插手。这种心态在 GPT-4 时代是必要的在 GPT-6 时代是拖累。你要接受一个事实在具体执行上模型可能比你更懂怎么走。你的价值不在于告诉它每一步怎么走而在于告诉它什么叫做得好、什么叫做不能碰。这就像带团队。好的管理者不会盯着每个人怎么敲键盘而是把目标、标准、边界说清楚然后让团队自己想办法。7.2 需要补的新技能放手之后有几项技能变得更重要第一是任务分解的颗粒度把控。拆得太细等于没放手拆得太粗Agent 容易跑偏。我的经验是拆到一个可验收的成果这个粒度比如整理出待办清单是一个任务把清单写进表格是另一个任务。第二是工具设计。Agent 的能力上限取决于你给它的工具。工具设计得好Agent 如虎添翼设计得差Agent 寸步难行。工具要原子化、语义清晰、错误信息友好。第三是评估体系。放手之后你怎么知道 Agent 干得好不好必须有自动化的评估。我一般会准备一批标准测试用例每次改完 Agent 配置就跑一遍看通过率有没有下降。7.3 一个判断标准你是在教它做事还是在告诉它要什么最后分享一个我自己的判断标准。每次写提示词或者配 Agent 的时候我会问自己一句我现在是在教它做事还是在告诉它要什么如果发现自己在写第一步做 A第二步做 B那就是在教它做事说明我还没放手。如果写的是目标是 X不能碰 Y做完给我看 Z那就是在告诉它要什么这才是放手的状态。这个标准帮我砍掉了大量不必要的提示词也让我从调提示词调到吐的状态里解脱出来。说到底GPT-6 最大的变化不是它变聪明了多少而是它终于聪明到值得你信任它自己去做。提示词工程不会消失但它的重心会从控制转向委托。学会放手不是偷懒是把你的精力从执行细节里抽出来放到真正需要人判断的地方——目标、边界、验收。我在实际项目里的体会是放手初期会有一段不适应期总觉得不踏实。但一旦护栏设好、验收跑通你会发现 Agent 能扛的事比你想象的多得多。真正难的从来不是让 AI 干活而是你敢不敢让它自己干。
