不会聊天的AI：从ChatGPT到任务执行Agent的架构与实践

最近圈子里都在聊一个挺反直觉的AI项目参与打造ChatGPT的那批人转头做了一个不会聊天的AI。刷到这条消息的时候我正在跟某个大模型扯皮——它帮我写了三版代码最后发现需求理解错了。这种“聊了个寂寞”的体验估计不少人都懂。而这个新项目恰恰反着来不跟你聊天只把你丢过来的任务做完。消息传开后不少AI工程师和产品经理都坐不住了这到底是噱头还是真把路走通了我翻完公开的技术资料又自己动手搭了个简化版下面把思考过程、核心设计和个人踩坑一起分享一下。说明本文所有内容基于公开资料和个人实践总结不涉及具体产品名与商业机密。1. 这个「不会聊天」的 AI到底是什么来头1.1 从ChatGPT到干活AI一句话概括它ChatGPT大家已经很熟了它的核心是对话你问一句它答一句多轮下来能写论文、编代码、做翻译。但它本质上是“你说什么它答什么”。而这个新项目不一样它的默认交互不是对话而是一个任务清单。你给它“帮我把这周的销售数据汇总成PPT里的图表并发送到邮箱”它不会问你“好的请问您希望用什么颜色”而是直接调用脚本、查库、生成图表、写邮件、发出去最后给你一个带附件的链接。说白了它把AI从“顾问”变成了“实习生”。你关注的不再是它说了什么而是它做了什么。这种定位上的差异背后是整个技术栈的取舍。聊天机器人的核心是“生成下一句话”而干活AI的核心是“生成下一步行动”。看起来就差几个字实际做起来完全不同。聊天可以含糊任务不能含糊——发错一封邮件成本比聊错一句话高得多。1.2 团队为什么有底气“砍掉聊天”参与打造ChatGPT的这批人最擅长的其实不是单纯的模型训练而是把模型稳定地用到生产环境里。ChatGPT从实验室走向全球几亿用户过程中攻坚的难题包括怎么让模型不胡说、怎么对齐人类偏好、怎么把推理成本压下来。这几个能力放到Agent场景里同样适用甚至更关键。因为对话聊错了可以回退一句任务执行错了可能会误发邮件、改错配置损失是实打实的。所以他们不是“不会做聊天”而是把聊天技能主动弱化把对齐、规划、工具调用这些底层能力强化。这个选择很聪明与其在大模型聊天赛道里内卷不如去找一个更接地气的落地场景。你会发现真正让他们有底气的不是模型本身有多强而是他们知道怎么把一个AI系统稳在真实业务里跑起来。这恰恰是很多小团队做Agent时最缺的东西。2. 为什么一定要做成「不会聊天」——产品设计背后的取舍2.1 聊天的三大隐性成本为什么非要砍掉聊天我在实际调模型时体会很深。第一个是Token成本。一次多轮对话经常有一半Token浪费在寒暄和补充解释上。比如你问“帮我查一下昨天北京的天气”模型可能会先回复“好的查询天气需要调用天气API请稍候我来为您查询”。这句话本身不产生任何价值却消耗Token、拉高延迟。如果是任务型场景这种冗余会被放大——每一个不必要字都是钱。第二个是意图漂移。聊得越多任务边界越模糊。用户本来要的是“查天气”聊到后面可能变成“分析气候变化趋势”需求不断膨胀AI搞不清哪个才是最终目标。我见过很多AI产品的通病用户一开始提了个小需求AI“贴心”地追问细节反而把需求带偏。在任务执行场景里意图漂移意味着返工和事故。第三个是结果难以结构化。聊天输出是自然语言机器没法直接拿去执行后续流程还得二次解析。哪怕是“帮我设置一个明早八点的提醒”模型也要识别意图、抽取时间、确认动作才能最终落到系统调用上。多这一步就多一个出错点。所以做一个不会聊天的AI本质上是把交互成本压到最低把信息密度提到最高。不是它不会聊而是“不聊”本身就是一种优势。2.2 不聊天的AI怎么工作四个关键环节它的工作链路跟ChatGPT完全不同。输入是一份结构化的任务单比如JSON任务描述、约束条件、需要调用的工具列表、交付格式。AI要做四件事第一理解任务目标把模糊描述转换成明确的可执行计划第二把计划拆成步骤给每一步分配工具第三执行工具调用比如访问数据库、调用API、操作浏览器第四汇总结果按任务单里的格式输出。整个过程不需要一句多余的“收到”“正在为您处理”。每一步都可以被审计失败也能快速定位到具体工具和参数。对比一下ChatGPT的回复像一个“黑箱”而干活AI的每一步操作都有日志——它调了什么工具、传了什么参数、拿到了什么结果全部记录在案。这种可审计性对企业用户尤其重要。你不敢让一个聊天机器人直接碰生产库但你可以让一个带日志、可回滚的执行Agent去跑固定流程。2.3 它适合什么场景不适合什么场景这种AI最适合的是“目标明确、流程可拆解、结果可验收”的场景。我列举几个身边常见的场景典型任务为什么适合数据报表每天拉取业务数据生成图表并发送流程固定输出格式明确自动化测试按测试用例执行汇总失败项步骤可追踪结果可判定内容聚合抓取竞品信息整理成结构化表格输入输出都是结构化数据软件工程根据Issue改代码、跑测试、提交PR工具链成熟验收靠CI客户工单按规则分类自动回复常见问题有标准操作流程异常可转人工它不适合做什么发散式的头脑风暴、情感陪伴、开放式写作。你要它陪你聊人生哲学它只会回你“任务不在支持范围”。这也解释了为什么团队敢挂“不会聊天”的招牌——他们根本不打算覆盖所有场景而是在“任务执行”这个赛道做到极致。产品定位说白了就是取舍他们选择把“做”这件事做穿。3. 核心细节拆解不聊天 AI 的关键机制3.1 任务单把“人话”变成结构化指令和API打交道久了就会明白非结构化文本是所有自动化流程的噩梦。所以这种AI的第一层设计就是定义任务单格式。我参考了几个开源项目写了一个简单的JSON示例你可以直接抄{ task_id: weekly_report_2025_0614, goal: 汇总本周销售数据生成折线图并发送邮件给manager, constraints: [只包含华东区数据, 折线图格式为PNG, 邮件主题必须包含周报], tools_allowed: [database_query, chart_generator, send_email], output_format: email_sent_link }写清楚goal、constraints、tools_allowed、output_formatAI就不需要“猜”你的意图。相比对话式一轮轮澄清这种方式一次性把规则说清出错概率大幅下降。当然不是所有场景都能提前结构化。如果任务太开放可以允许一个澄清步骤但限制在“一次性补充问题”而不是无限对话。我在实际使用中会把所有“必填字段”提前定好就像表单校验一样缺了就不发出去。这样AI永远不会因为理解偏差而自由发挥。3.2 规划器只输出可执行的步骤不要解释任务单拿到后要交给一个规划大模型。关键点在于提示词怎么写。我试过很多种最稳的是要求模型输出严格的JSON步骤列表每个步骤包含动作、参数、依赖关系。下面是我压箱底的提示词骨架你是一个任务规划器。用户会提供一个任务单JSON。你的任务是将它拆解为一个步骤列表。 要求 1. 每一步必须是一个可执行的工具调用不能是自然语言描述。 2. 输出JSON数组格式为[{step: 1, tool: database_query, input: {...}, depends_on: [0]}] 3. 不要输出任何解释、问候、总结。只输出JSON。 4. 如果任务信息不足输出{error: need_more_info, question: ...}核心就是那四个字“只输出JSON”。实践中这句约束能极大降低模型“话痨”的概率。你会发现同一个模型加了这条约束后推理时间变短返回内容也能直接喂给执行器。另一个小诀窍是在提示词里加一句“你的回复会被程序直接解析任何多余字符都会导致系统崩溃”。这句话对很多模型都很管用它会自动进入“严格执行模式”。3.3 工具层把API和操作抽象成统一接口规划器只负责“想”真正“做”的是工具层。工具层像一个注册表每个工具包括名称、参数schema、执行函数。我习惯这样组织TOOLS { database_query: { description: 查询数据库并返回结果, parameters: {sql: string, database: string}, function: run_sql }, chart_generator: { description: 根据数据生成图表文件, parameters: {data: list, chart_type: string, format: string}, function: make_chart }, send_email: { description: 发送邮件, parameters: {to: string, subject: string, attachment: string}, function: send_mail } }执行器拿到规划器的输出后按步骤依次调用函数并把前一步的返回值传给后一步的input。比如先查数据库得到data一列再作为chart_generator的data参数。这里有个大坑模型生成的工具名或参数经常会有偏差所以工具层一定要做schema校验不符合就直接终止不要硬调。我见过太多Agent在“伪正确”的参数上跑飞最后生成了莫名其妙的输出。宁可失败重来不要让错误数据往下游流。3.4 交付层用验收协议界定“干完了”任务结束后把最终产物交付给用户。产物可以是一个文件链接、一个PR链接、一条消息记录。为了避免“好像是做完了又好像没做完”建议在任务单里output_format里写明验收标准。比如“output_format: email_sent_link那么系统就返回导出的截图。比如“email_sent_link”那么系统就返回邮件发送的回执链接如果是“file_path”就返回文件路径。这样每个任务都有明确的完成标志。我还习惯在交付层加一个“人工确认”开关尤其是涉及发送邮件、删除数据、发布内容的操作。默认情况下不开启一旦开启Agent执行到敏感步骤时会停下来等人工确认。这个设计在初期尤其重要因为它给了用户安全感。等到信任建立了再慢慢放宽权限。4. 实操复盘我搭了一个最小版“不会聊天”AI4.1 环境准备与配置前面讲了不少架构这一节我跑一个最小实现。假设目标很简单查一个城市天气然后把结果写入一个文本文件。它没有ChatGPT式的回复只有最终文件。需要准备的东西不多Python 3.9以上、openai库或者任意兼容OpenAI协议的SDK、一个API key。这里我建议把API base和模型名写成配置项方便切换不同厂商。我在实验中用的是一个公开的兼容接口模型名填的是qwen-plus下方代码你换成自己的就行。配置项放在环境变量里不要写死在代码中。一方面是安全习惯另一方面是灵活切换模型方便。我踩过坑曾经为了图快把API key硬编码进脚本结果传到Git仓库被自动扫描出来搞得整个key作废。从那以后所有示例代码我都用os.getenv。4.2 规划器和执行器的完整实现完整代码如下很短import os import json from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) def get_weather(city): # 模拟天气API实际换成requests调第三方接口 return {city: city, weather: 晴, temp: 32} def write_file(filename, content): with open(filename, w, encodingutf-8) as f: f.write(content) return f文件已保存至 {filename} TOOLS { get_weather: {function: get_weather, params: [city]}, write_file: {function: write_file, params: [filename, content]} } def planner(task_json): prompt f你是一个任务规划器。任务单如下 {task_json} 请把任务拆成步骤每一步使用给定工具。 可用工具{list(TOOLS.keys())} 输出JSON数组每个元素格式{{tool: ..., input: {{...}}}} 不要输出任何解释只输出JSON。 resp client.chat.completions.create( modelqwen-plus, messages[{role: user, content: prompt}], temperature0 ) content resp.choices[0].message.content start content.find([) end content.rfind(]) 1 return json.loads(content[start:end]) def executor(steps): outputs {} for idx, step in enumerate(steps): tool_name step[tool] tool TOOLS[tool_name] final_input {} for k, v in step.get(input, {}).items(): # 支持引用上一步输出input值为{$ref: 0} 表示用outputs[0] if isinstance(v, dict) and $ref in v: final_input[k] outputs[int(v[$ref])] else: final_input[k] v outputs[idx] tool[function](**final_input) return outputs task { goal: 查询上海天气然后写入 weather_report.txt, tools_allowed: [get_weather, write_file] } steps planner(task) result executor(steps) print(result)这个例子虽然简单但把“规划—执行”闭环跑通了。注意executor里我用了一个$ref机制让后一步能拿到前一步产出的数据。真实场景里面很多坑都是因为步骤间数据传递没接好这个机制是通用的。如果你跑通了这个例子后面加工具、加条件判断、加重试逻辑都是顺理成章的事。4.3 实测效果与参数调优记录跑下来最大的感受是temperature一定要设置成0或者尽可能低。任务规划不允许随机性。第二个是成本控制如果任务步骤超过10步一次任务消耗的Token约等于50轮聊天这还不算工具返回内容。所以我给planner设置了max_steps上限一旦超过就自动终止并返回错误。你可以在提示词里加一句“最多允许5步”经验值效果明显。我同时记录了几次任务的耗时和Token消耗任务步骤数耗时Token消耗结果查天气并写文件23.2秒约1.2K成功查两个城市并汇总45.1秒约2.8K成功自定义复杂任务9Fail约7K失败工具参数错误你会发现简单任务的成功率很高复杂任务非常容易翻车。第一次跑复杂任务失败后我去查日志发现模型把write_file的content参数传成了字典对象而不是字符串。schema校验应该挡住这种错误但我在雏形阶段没实现后来才补上。这也是Agent开发中最典型的过程先跑通再加固。5. 踩坑实录不亲自跑几遍这些问题根本遇不到5.1 模型忍不住“话痨”导致JSON解析崩溃哪怕prompt里写了“只输出JSON”有时候模型还是会来一句“好的我来为您规划这个任务”。如果后面返回的内容不是纯JSON解析就会崩溃。我的解法是两层第一层提示词里再加“你的回复将会被程序解析任何多余字符都会导致系统故障”第二层解析时做一次“去包裹”处理把代码块、注释剥掉。但不要只依赖第二层因为第一层能显著降低概率。我还见过更隐蔽的情况模型输出的JSON里突然出现一个中文逗号json.loads直接报错。这属于编码问题好的做法是先把替换成,再尝试解析。这种小坑不跑一遍根本发现不了。5.2 工具失败后无限重试白烧Token真实世界API总会失败比如数据库连不上、邮件服务超时。如果不处理执行器会一直重试或者直接把错误信息当结果传给下一步最后生成一堆垃圾数据。我的做法是每步工具统一抛异常执行器捕获异常后把错误信息返回给规划器让规划器重新调整步骤。这个“重规划”机制非常有用但要注意增加一个最大重试次数否则遇到持续性故障会一直空转。举个例子一个任务要查A、B两个库A库挂了规划器原本的步骤是“查A库→查B库→汇总”。捕获异常后规划器会重新规划成“跳过A库→查B库→汇总并标记A库异常”。这个效果比直接失败好很多。但如果A库持续挂1小时每次重试都消耗Token必须设置“最多重规划3次”之类的硬上限。5.3 上下文窗口是隐形天花板任务规划如果步骤多每个工具返回又大很可能中途就把上下文撑爆。我见过一个抓取任务光前三步返回的数据就超过40K Token第四步开始模型就开始“失忆”不再遵守任务约束。建议工具层对返回数据做截断只保留摘要或关键字段也可以在任务单里写明“只保留必要数据”。这一步对长链路任务至关重要。另一种解决方案是把长任务拆成短任务用“状态文件”在多个Agent调用之间传递上下文。比如一个抓取任务先让第一个Agent抓取并压缩成摘要第二个Agent基于摘要生成报告。这样每个Agent只关注一个段落上下文压力小很多。这也是为什么很多Agent框架引入“子Agent”概念——本质上是把上下文分配到多个进程里。5.4 成本翻车的血泪教训有一次我开了一个Agent跑竞品分析规划器生成了12步其中4步是爬取网页返回内容巨大。最后一算消耗的Token相当于我平时两个星期的量。从那以后我给所有Agent任务加了两条硬规则一是工具调用前先估算返回大小超过阈值拒绝调用二是设置单任务Token预算超过就停。别指望“省”出来一开始就定预算。我列了一个成本控制速查表你也可以参考控制手段实施方法效果限制步骤数提示词里加“最多5步”防止规划失控截断工具返回只返回前1000字符或摘要降低上下文膨胀单任务预算调用前统计Token增量超阈值终止防止成本雪崩复用上下文相同系统提示词只传一次省重复Token成本问题在Demo阶段不痛不痒一旦跑到真实业务尤其是频繁调度时分分钟烧出天价账单。现在做Agent的人普遍都会把成本监控当成必备能力而不是事后补救。6. 从ChatGPT到干活AI我的一些思考6.1 为什么“会聊天”不等于“会干活”回头看ChatGPT是把大模型推给大众的里程碑它证明了AI能“说”。但“说”只是手段“做”才是目的。这个不会聊天的AI走的是另一条路把大招从“生成回复”转向“生成行动”。它让我想起早年做企业软件的时候大家想的不是怎么让系统更会聊天而是怎么让系统把事情办妥。AI也一样当一个比实习生还便宜的Agent能自动完成报表、发邮件、改BUG时它的价值比任何聊天窗口都大。聊天能力当然重要但它是“前端”不是“后端”。一个只能聊天不能干活的AI就像一位侃侃而谈但是不上手的顾问。前几天还有一个朋友问我ChatGPT都能帮我写代码了还需要这种Agent吗我说聊天式写代码本质上是你把需求翻译给模型再把模型代码抄回去而干活AI是直接从Issue到PR中间你只做验收。后者才是真正的闭环。6.2 多AI协作可能是下一站从技术趋势看下一个爆发点一定是多AI协作。聊天AI负责理解和表达干活AI负责执行中间通过事件总线调度。比如你日常用的对话助手收到一句“帮我处理发票”它把任务拆开分给票据识别Agent、财务规则Agent、Outlook发送Agent最后把结果汇总给你。整个过程用户只感知到一次交互后面全是Agent在干活。这个方向参与打造ChatGPT的人来做天然有优势——他们最懂模型对齐和系统扩展。我在自己的小项目里试过两个Agent协作一个负责从数据库拉数据一个负责写报告。它们通过共享一个JSON文件传递中间状态效果出奇地好。数据Agent返回的是结构化表格报告Agent拿到的不是对话文本而是干净的表格结构报告质量高很多。这种模式值得每个做AI工具的人研究。6.3 给想试试的人三条建议第一先找一个每天都做的重复任务下手不要一上来就做通用助手。比如整理表格、生成日报、批量改文件名这类任务边界清楚不容易失控。第二把“任务单”设计放在第一位。花一天时间定义输入输出格式比写一周代码更值得。很多Agent跑不好本质上是任务单里的字段没定义清楚。第三一定要加日志和监控。我见过太多Agent跑挂了之后开发者也说不清在哪一步出错。有了步骤日志定位问题就是几秒钟的事。我个人在实际操作中的体会是不要被“大模型只会聊天”框住。同一个模型换一套输入输出协议就能变成执行引擎。这个“不会聊天”的项目本质上就是做了一个很极端的封装——把大模型从“嘴替”变成“手替”。如果你也正在做AI相关的事情我强烈建议你也试试这个思路不需要多复杂的框架一个小脚本就能体会到“让AI干活”和“让AI聊天”的天壤之别。最后再分享一个小技巧不要让Agent在在线对话里运行而是把它做成一个后台任务。你提交任务单它完成后再提醒你。这样既不会被“正在思考”卡住也方便你对每一步做审计。这个方向值得继续跟下去。