上周OpenAI发布Dots的时候我正蹲在群里看开发者们争论它和Codex到底什么关系。有人说是套壳有人说是ChatGPT的升级版也有人一脸懵OpenAI不好好做大模型怎么开始折腾这种“派活”的东西了我花了两天把公开资料翻完又自己上手试了试结论很明确Dots不是一个小功能它是OpenAI对“AI Agent到底该长什么样”的一次明牌表态。而它背后真正值得琢磨的问题其实就一句话——AI Agent为什么开始从“回答问题”走向“执行工作”这篇就围绕这句话展开。我会拆解Dots的产品形态讲清楚它和Codex、ChatGPT之间的关系再往深一层聊聊Agent范式转移的技术逻辑最后结合我自己搭Agent的实操经验说说“让AI干活”这件事在工程上到底有多难、坑在哪、怎么绕。不管你是写代码的、做产品的还是纯粹想搞明白AI接下来往哪走的人这篇应该都能给你点有用的东西。1. Dots到底是什么一次从“聊天”到“派活”的产品形态跃迁1.1 先把它和ChatGPT、Codex的关系捋清楚很多人的第一个疑问是Dots是不是又一个ChatGPT不是。ChatGPT的核心交互是对话框你问一句它答一句答完拉倒。即便后来加了联网、加了记忆它的本质仍然是“问答系统”——你出题它交卷过程不可控结果不可复现。Codex则完全是另一个物种。OpenAI对Codex的定位是“command-line coding agent”你登录之后它直接跑在你的终端里能读写你的代码仓库、执行测试、提交PR。换句话说Codex是一个住在你开发环境里的“编外工程师”它干的是活不是聊天的天。Dots更像是一个介于两者之间的、面向更广泛场景的“任务执行平台”。我看完官方文档和演示后的理解是你把自己的账号串联起来可能是GitHub、可能是Slack、也可能是一些公开数据源然后你只要用自然语言描述一个任务——比如“帮我把这个仓库的issue分类整理成周报”——Dots会在云端拉起一个隔离的工作环境自己拆解任务、写代码、调用工具、跑结果最后把成果交付给你。整个过程不需要你写一行代码。所以三者可以这么理解ChatGPT是顾问只动嘴Codex是驻场工程师在你眼皮底下干活Dots是一个拥有独立工位的远程外包团队你把需求丢过去它自己安排人去干干完给你交付物。1.2 Dots的核心能力拆解公开信息显示Dots有几个关键设计值得注意。第一是任务式交互。它不再按“一轮对话”来组织而是按“一个任务”来组织。你创建的是一个任务这个任务有自己的状态——排队中、执行中、已完成、失败了。这种组织方式说明它的底层是把Agent当成一个长期运行的工作单元来设计的而不是一组短命的问答序列。第二是云端沙箱执行。Agent干活的地方不是你的本地设备而是OpenAI管理的云端环境。这个设计非常关键它意味着Agent可以不受你电脑性能和网络环境限制地跑重型任务也意味着OpenAI可以对Agent的行为做统一的安全审计。代价就是你得接受数据和代码在云端流转这对个人开发者问题不大但对有数据合规要求的企业来说是需要额外考虑的点。第三是对Agent集群的支持。Dots不是只能创建一个Agent而是可以按需创建多个让它们各管一块共享一个工作空间。这个思路其实已经有点“AI同事群”的意思了——未来你管理的不是代码而是一群AI员工你需要做的只是给它们分配目标、协调资源、验收结果。第四是生态接入。Dots支持连接外部的账号和数据源。目前公开的信息里我们能看到它和开发工具、协作工具打通的迹象加上Codex CLI现在也支持“sign in with ChatGPT”说明整个Agent产品矩阵正在被纳入同一个身份体系和任务体系里——账号即工作台登录即开工。1.3 为什么OpenAI选在这个时间点推出Dots现在回头看Dots的出现几乎是必然有三个推力把它推上了牌桌。模型能力到了能干活的水准。以前不是不想让AI干活是模型做不到。让大模型独立执行多步骤任务需要它具备稳定的长上下文、可靠的工具调用能力、以及出错后的自我纠偏能力。这几样东西在GPT-3.5时代都是奢侈品在现在的主流模型上已经算是标配了。能力到位产品形态才能升级。工程基础设施也成熟了。沙箱技术、函数调用、MCP协议、Agent可观测性这些底层组件在这两年里被快速补齐现在搭一个能稳定运行的Agent环境成本比两年前低了一个数量级。OpenAI自己下场做产品正好可以把这套基础设施的威力展示出来让外界看到“Agent不是demo是可以交付的东西”。行业竞争逼着它从“卖模型”转向“卖结果”。当OpenAI的API成为行业标准之后单纯卖模型的生意就陷入了价格战和同质化竞争。要建立新的护城河就必须往价值链上游走从提供模型能力变成提供“完整的任务解决服务”。Dots就是这个战略转向的载体。它向市场传递的信号非常直接不要只把AI当成一个写作工具或聊天玩具它现在可以为你完成实际工作。2. 从“回答问题”到“执行工作”Agent范式转变的四个本质变化2.1 目标驱动取代指令跟随我问“今天天气怎么样”这是指令跟随模型的任务就是解析问题、检索答案、组织回复。但如果我告诉一个Agent“帮我规划一下下周去杭州出差的行程包括交通、住宿、会议安排”这就变成了目标驱动——Agent要自己决定怎么拆解这个目标查哪些信息按什么优先级处理最终交付一份可用的行程单。这个转变的本质是控制权的转移。指令跟随时代人类是操作员每一个动作都要人下指令目标驱动时代人类变成了管理者只需要定义目标、划定边界、验收结果。中间那些“怎么做”的路径全部由Agent自主规划。我打个比方指令跟随就像遥控汽车你每按一下方向键它才动一下目标驱动就像给你的车装上了导航你只需要输入目的地路径规划、交通规则、避让行人这些事它自己处理。Dots这类产品的意义就是让AI从“遥控汽车”变成了“自动驾驶汽车”。2.2 工具调用取代知识检索过去的AI助手的强项是“知道”是知识库和信息的搬运工。但“干活”这件事光知道是不够的你得会操作。要发一封邮件你得能调用邮件客户端要更新一份表格你得能读写Excel文件要部署一个服务你得能连接服务器执行命令。这些能力统称为工具调用。Agent和聊天机器人的分水岭就在这里聊天机器人只负责把话说漂亮Agent必须把事办成。在技术层面工具调用已经被标准化了。OpenAI率先在API里定义了函数调用function calling的标准范式后来MCPModel Context Protocol的推出进一步把工具接入变成了一套通用协议。现在一个Agent想要接入一个新工具不需要为每个平台单独写适配代码只要实现了MCP标准接口就能被Agent直接调用。这种“标准化”是Agent能规模化落地的技术前提。如果没有这套标准每个Agent都是信息孤岛要接十个工具就得写十套集成工程成本会直接拖垮这个品类。有了MCP之后工具生态就像手机App Store一样快速丰富起来Agent能干的活也随之指数级增长。2.3 状态化取代无状态聊天是天然无状态的你把上下文说清楚AI回复完这段关系就结束了。但执行任务不同任务是持续性的、跨时间的、可以被打断和恢复的。典型场景是这样的Agent早上开始跑一个数据分析任务中午你给它加了新的需求下午任务中断第二天要继续从断点接着跑。传统的对话模型做不到这些因为你每一次调用都是全新的模型不记得昨天做了什么。Agent则必须维护自己的状态——当前任务进度、中间结果、已完成步骤、待处理清单。这背后的工程结构从“无状态的HTTP请求”变成了“有状态的长期运行进程”。Agent需要一个持久化的记忆系统可能是向量数据库、也可能是KV存储用于记录任务执行过程中的关键信息需要一套任务编排引擎来处理任务的暂停、恢复、重试还需要一个清晰的工作区来存放中间产物。Dots把工作空间做成云端共享本质上就是在为这种状态化需求提供底层支撑。你创建的任务、生成的文件、跑出来的结果都存在云端无论你在哪台设备上登录都能接着上一次的进度继续。这个体验上的变化看似不起眼但它是Agent从“玩具”走向“生产力工具”的关键一步。2.4 自主决策取代逐句确认以前的AI产品用户体验是“你问它答”它永远在等你确认下一步。Agent则不一样它被授予了一定的自主决策权会在目标范围内自己决定执行路径而不是每一步都回来问人。这带来一个微妙又重要的变化信任边界。你愿意把多少决策权交给Agent决定了它能在多大程度上帮你干活。如果每个步骤都要确认Agent就退化成了高级搜索框毫无效率可言如果把权限全给了又可能在一个小错误的放大下造成不可挽回的损失。所以我一直认为Agent产品设计的核心不是AI能力而是权限管理能力和失控兜底能力。优秀的Agent产品要让用户能精细地控制这个任务你可以自行决定那个操作你必须经过我批准这些资源你可以碰那些资源你绝对不能碰。平衡好“放权”和“管控”Agent才能真正从“演示品”变成“生产力工具”。3. 让AI“下地干活”执行型Agent的技术骨架与实操要点聊完了趋势说点实在的。我在过去一年里自己动手搭过几个执行型的Agent有用于自动化报表的有用于代码仓库维护的有用于定时抓取信息并汇总的。说实话从“能跑demo”到“能稳定干活”中间距离比想象中大得多。这一节把我认为最核心的架构认知和工程要点分享出来。3.1 执行型Agent的通用架构长什么样不管底层模型是谁凡是“能干活”的Agent基本都遵循同一个分层的架构规划层Planning接收任务把大目标拆解成可执行的小步骤决定先做什么后做什么。这个层通常依赖强推理能力的模型是Agent的“大脑”。工具层Tools封装一切Agent能调用的外部能力包括API、代码执行器、数据库、浏览器等。工具层是否丰富、是否稳定直接决定Agent“能干多少活”。记忆层Memory保存任务相关的信息和历史状态包括短期记忆本次任务的上下文和长期记忆跨任务的经验和事实。执行层Execution真正去跑工具、跑代码、验证结果的地方。执行层需要可靠因为Agent的每个决策最终都要落到这里变成动作。这四层缺一不可。规划层决定聪明程度工具层决定能力边界记忆层决定连续性执行层决定稳定性。我自己的项目里比较常用的是FastAPI LangChain/LangGraph这套组合。FastAPI负责提供HTTP接口让Agent能力可以被外部系统调用LangChain提供丰富的工具集成从搜索到数据库操作都有现成封装LangGraph则专门用来处理复杂的Agent状态流支持分支、循环、条件判断这些控制逻辑。这套技术栈的文档完整、社区活跃属于“先跑起来再优化”的最优解。如果你是从零开始想搭一个Agent我的建议是不要一上来就追求大而全。先用LangGraph搭一个最小闭环——任务输入、规划、调用一个工具、返回结果——跑通了再加第二、第三个工具。3.2 核心工程挑战一Agent怎么扛并发和降延迟这是所有想把Agent产品化的团队迟早会遇到的问题。普通聊天的并发模型是“请求一来回答一发连接就断了”非常轻量。Agent完全不一样一个任务可能会持续跑几十秒甚至几分钟期间要调用多次模型、执行多轮工具整个生命周期占用的资源是聊天的几十倍。如果用最朴素的同步方式处理Agent请求一个任务占用一个工作进程并发稍微一上来服务马上被打满。我踩过的坑就是这样开压测工具模拟20个并发任务服务直接雪崩数据库连接池耗尽任务队列堆积到不可用。后来被迫做了三件事才算稳定下来把任务处理改成异步队列模式。任何Agent请求进来先入队由后方Worker异步消费而不是用一个阻塞进程等着它完成。这个改造本质上把“并发处理”和“同步等待”解耦了系统能同时接收大量任务再根据资源情况一个个消化。对模型调用做限流和退避。OpenAI的API有速率限制Agent一次任务里可能连续调用十几次模型不控制节奏分分钟触发429错误。我的经验是在Agent里内置一个简单的令牌桶控制每秒最多发起多少次模型请求遇到限流错误不要立刻重试而是指数退避后重试稳定性会好很多。任务执行设计成可重试且幂等。所谓幂等就是同一个任务执行两次结果不能有偏差。因为Agent在复杂任务里很容易碰到中间步骤失败此时必须能安全地从断点重跑而不是反复执行导致数据重复写入。3.3 核心工程挑战二Agent的Token成本怎么算明白热搜词里有人问“agent token是什么意思”这个问题问得特别实在。Token是大模型计费的最小单位可以粗略理解成“字词片段”。聊天场景里一次对话消耗几百到几千token而一个执行型Agent跑一次任务消耗的量级是几万甚至几十万token。为什么差这么多因为Agent执行任务时每一次工具调用都要把最新的结果“喂”回给模型做下一步推理而且为了保持上下文连贯消息列表会像滚雪球一样越滚越大。一次任务下来模型可能要推理十几次累积的Token量是肉眼可见地暴涨。我给自己做过一次统计一个“抓取行业新闻并按主题分类汇总”的Agent任务消耗约4万token。如果按主流模型价格估算单次任务成本在几块钱人民币。听起来不贵但如果这个任务是每小时跑一次一个月就是几千块。所以Token成本根本不是“技术问题”而是“商业模式问题”。控制成本有两个实用的土办法。一个是控制上下文长度只保留当前步骤相关的信息历史步骤压缩成摘要不要一股脑全部塞给模型。另一个是把大任务拆成小Agent各司其职每个Agent只需关注自己领域的上下文比单个大Agent通吃全局要省钱得多。还有个容易被忽视的点Agent的Token消耗和任务成功率直接相关。任务失败一次重跑一轮成本就翻倍。所以与其在模型选型上省参数钱不如先把工具层做稳、把异常处理做好让任务一次成功的概率提上来这才是最省钱的手段。3.4 一个落地案例让Agent自动生成运营日报拿我目前维护得比较久的一个Agent举例它的任务是每天早晨自动从公司数据库拉取前一天的核心业务数据生成一张运营日报推送到团队群。整个流程其实就是上面说的架构的完整展示。规划层Agent启动后先识别“今天该汇报哪些指标”自动生成数据查询计划确认哪些表、哪些时间范围、哪些聚合口径。工具层包含数据库查询工具、报表生成工具、群消息推送工具。记忆层会记住上周同期的数据输出报告时自动计算环比变化。执行层定时调度触发查询完成、生成报告、推送结果全程无人参与。这个Agent看着简单实际调试过程挺折腾的。最开始它总是搞错时间范围把昨天的数据算成前天的后来加了显式的时间计算规则才解决。还有一次它推送的报告格式乱套了排查半天发现是数据库返回空值导致它走了异常分支。这些问题的修复靠的都是在Agent的每个关键节点把状态输出抓出来看而不是让它在黑盒里瞎跑。所以我特别想强调一件事Agent越是自主越需要可观测性。你要能随时看到它当前在做什么、卡在哪一步、为什么做了某个决策。没有观测能力的Agent跑起来就像开一辆没有仪表盘的汽车你根本不知道它什么时候会翻车。4. 常见问题与排查经验Agent落地最容易踩的坑4.1 工具调用失败与重试逻辑工具调用是Agent执行任务的物理基础也是最容易出问题的环节。网络抖动、接口限流、参数格式错误、权限不足……任何一个原因都能让工具调用失败而一次失败就可能让整个任务链条断掉。我常用的排查顺序是先看日志里的原始报错判断是网络层、协议层还是业务层的问题然后看工具返回的错误码是否被正确传递给了模型很多Agent的问题出在模型根本不知道工具失败了它还在基于错误结果继续推理最后检查重试逻辑是否在失败后自动重试、重试间隔是否合理、重试次数上限是否设置。实操上有一个很重要的细节工具调用的结果一定要完整回传给模型包括报错信息。很多Agent把工具返回结果截断后丢给模型模型看到不完整的信息做出了错误的后续决策。宁可传的上下文长一点也不要丢关键错误信息。4.2 上下文爆炸与记忆裁剪前面提到Agent执行任务会累积大量上下文这就是“上下文爆炸”。模型能接收的token是有限的虽然窗口越做越大而且越长的上下文推理速度越慢、成本越高、注意力也越分散。处理上下文爆炸我目前用的方案是分层记忆短期记忆保留最近两轮交互的完整信息中期记忆用摘要方式浓缩关键结果长期记忆只存结论性的内容比如“用户偏好Markdown格式的报告”。每一层都有各自的存储和裁剪策略Agent在推理时按需读取而不是把所有历史一股脑塞给模型。这就像人做事的逻辑你不会记住昨天走过的每一步路但你会记得昨天的目的地和途中的关键转折点。Agent的记忆系统也应该这样设计分清哪些需要完整保留哪些只需要留下结论。4.3 安全边界让Agent有权限但不能乱来Agent被授予工具调用能力之后安全就是绕不开的话题。一个能操作数据库、能发消息、能拉代码的Agent一旦被prompt注入攻击操纵后果可比一个聊天机器人严重得多。目前我实际在用的安全策略是权限最小化。给Agent的每一个工具调用都设定明确的权限边界比如数据库只读账号、只允许操作特定表、只允许访问特定目录。同时给敏感操作比如删除、推送、转账加一层人工审批闸门Agent执行到这类操作时自动停下来等待人工确认。还有一点是沙箱隔离。凡是Agent执行的代码一律放在隔离环境里跑绝对不让它在宿主机上直接执行。这一步没有商量的余地Agent写的代码没有经过严格审查前不能信任它。4.4 常见问题速查表问题现象最可能原因优先排查路径Agent中途停止没有继续执行模型单次输出达到长度上限检查输出token上限配置考虑降低单次输出要求Agent反复执行同一个无意义循环规划层的目标拆解不收敛检查任务目标是否清晰是否给了明确的终止条件工具调用总是返回参数错误工具Schema定义与实际接口不一致对比Schema参数类型与实际API要求特别是枚举值任务结果不一致时好时坏模型温度参数设置过高降低temperature对关键任务建议设为0或接近0Agent响应越来越慢上下文过长模型推理变慢增加记忆裁剪策略定期压缩旧上下文模型被用户prompt带偏缺少角色约束和指令过滤在系统提示中强化边界对高危操作强制走人工审批4.5 为什么“回答型AI”和“执行型Agent”不是替代关系聊到这里有必要澄清一个认知误区。很多人觉得“回答问题”是旧时代Agent是新时代AI正在淘汰聊天机器人。真实情况没那么简单。回答型AI和Agent的关系更像是搜索引擎和数据分析师的关系。搜索解决的是“快速找到信息”的问题分析师解决的是“基于信息做判断和行动”的问题。两者适用场景完全不同短期内没有谁替代谁。事实上很多Agent内部仍然需要调用强大的问答模型来辅助推理。Agent负责规划、调度和执行问答能力作为其记忆和知识调用的基础支撑。所以更准确的说法是Agent不是取代了问答能力而是把问答能力包了进去并往上叠了规划、工具、执行、记忆这些新层次。这对从业者有个实打实的启示如果你想转Agent方向不要丢掉问答系统的功底。你以前积累的提示词工程、RAG检索增强生成、模型评测、效果调优的经验全部是Agent上层建筑的重要地基。5. Agent对开发者与行业的影响接下来该做什么5.1 从“写程序”到“让Agent写程序”开发者的角色变了Agent开始执行工作之后受冲击最直接的就是开发者这个群体。以前我们写代码是为了把人类的想法翻译成计算机能执行的指令现在Agent自己就能写代码、跑测试、修bug那么程序员的角色就变成了把业务目标翻译成Agent能理解的任务。这意味着两件事第一纯写代码为生的初级编码工作确实会被压缩第二能定义清楚任务、能设计Agent流程、能管理Agent质量的开发者价值会大幅上升。我认识的不少同行已经在主动转型把精力从“手写CRUD”转向“设计Agent工作流”和“搭建Agent评估体系”。判断一个 Agent 系统好不好靠的是评测集。你得准备一批标准任务每次改进之后跑一遍全量评测看成功率、完成质量、耗时、成本这几个指标有没有变好。没有评测体系就优化Agent系统基本就是闭着眼开车调了半天不知道是变好了还是变坏了。5.2 Agent渗透最快的几个场景按我自己观察和实际接触到的项目Agent渗透速度最快的场景有几个共性流程标准化程度高、中间产物数字化、每单价值密度适中。运维告警处理。监控告警本身是结构化的响应动作也相对标准化查日志、定位服务、重启、扩容非常适合Agent先做第一轮响应处理不了的再升级给人工。这个环节降本效果立竿见影。数据分析报表。从数据库取数、按模板生成图表、写分析结论这个流程天然适合Agent。我上面提到的运营日报就是典型案例定点定量、看得到效果、容易验收。代码仓库维护。依赖升级、issue分类、测试补全、文档同步这类体力活Agent做得又快又稳。Codex类的产品已经证明了这个方向的可行性。内容生产辅助。不是让Agent替代创作者而是让它承担资料整理、素材检索、初稿生成、格式校准这些支撑性工作把人的时间释放出来做真正的创造性决策。这些场景的共同点是最初文档和流程都是清晰的、可预期的所以Agent的容错空间比较大。最早落地的Agent项目一定是在这种“确定性任务”里出现而不是在需要大量不可预期判断的领域里。5.3 为什么要关注技术栈的新趋势热搜词里有“基于rust语言ai agent”和“spring ai agent”这些词说明整个行业已经在往不同技术方向探路。Rust这边因为内存安全和高性能非常适合做Agent的运行时基础设施Java生态这边Spring AI的成熟意味着Agent能力会被大量传统企业级后端系统采纳。我的判断是未来两年Agent的工程栈可能经历一次比较大的分化底层运行时追求性能和安全会往Rust、Go这边靠企业级应用会通过Spring AI这类框架快速集成Agent能力而最上层的编排和应用层会由LangGraph、Dify、扣子这类工具主导让非深度技术背景的人也能搭出能用的Agent。对开发者来说现在开始补Agent方向的技能树是很值得的投资。核心技能点就三个会设计Agent工作流规划、工具、记忆的编排、会做Agent工程化观测、评测、权限管理、会选型知道什么任务用什么模型、什么框架、什么架构。写在最后一点个人体会Dots发布之后我身边的人分成了两派。一派觉得这就是OpenAI正常的产品迭代不值得大惊小怪另一派觉得这标志着AGI又近了一步激动得不行。我自己的感受更接近中间态Dots真正值得关注的不是某一个具体功能有多惊艳而是它用产品形态确认了一个趋势——AI的能力评估标准正在从“会不会回答问题”变成“能不能把事情办成”。从技术实现角度看让Agent“干活”比让模型“说话”难的数量级不在于模型的智能程度而在于工程系统要负担的东西多了太多任务编排、工具链路、状态管理、错误恢复、成本控制、安全边界、效果评测。这一整套东西说起来不性感做起来全是细节但恰恰是它们决定了一个Agent产品是停留在demo阶段还是真的能成为生产力工具。我个人在搭建Agent的实操中体会最深的一点是Agent的上限由模型决定但下限由工程质量决定。模型再聪明如果工具层不稳定、上下文管理一塌糊涂、异常处理缺失最终交付也是废纸一叠。所以给想上手Agent的朋友一个很实际的建议——先从一个非常小、非常完整、验收标准非常清楚的任务开始把它跑稳、跑透、跑出自己能复用的套路再想着做更大的事。别一开始就憧憬组建一个Agent军团先把一个兵带出战斗力后面的事都好商量。