1. 从“会聊天”到“能干活”AI 能力跃迁的底层逻辑过去两年大家跟 AI 打交道的方式基本停留在“你问我答”这个层面。不管是写文案、改代码还是做翻译本质上都是模型在“动嘴”——它给你一段文字你自己拿去用。但最近一段时间圈子里讨论的方向明显变了越来越多的人开始关注另一件事能不能让 AI 直接“动手”把活干完这个转变的核心就是从“会思考”到“能干活”。前者指的是语言模型的理解和生成能力后者指的是模型能够调用工具、操作软件、执行多步骤任务最终交付一个可用的结果。听起来只是多了一步但背后的技术栈、交互范式和落地难度完全不是一个量级。我拿一个生活化的类比来解释。会思考的 AI 就像一个知识渊博的顾问你问他什么他都能答但他不会帮你打电话、不会帮你填表、不会帮你把文件归档。能干活的 AI 则更像一个助理你告诉他“帮我把这周的报销单整理好提交”他会自己去翻邮件、填表格、走流程最后告诉你“搞定了”。从顾问到助理中间隔的不是智商而是“手脚”。这篇文章想聊的就是这个跃迁过程。我会从技术演进的脉络出发拆解“会思考”阶段的核心能力是什么“能干活”阶段又需要补齐哪些关键模块然后重点讲清楚一个完整的“干活”链路是怎么跑通的。不管你是刚接触 AI 应用开发的新手还是已经在做 Agent 相关项目的从业者应该都能从中找到一些可以直接参考的思路和踩坑经验。2. “会思考”阶段语言模型到底强在哪2.1 理解与生成一切能力的起点要搞清楚“能干活”是怎么回事得先把“会思考”这件事说透。语言模型的核心能力就两个词理解和生成。你给它一段输入它理解你的意图然后生成一段符合预期的输出。这个过程中涉及的技术细节很多但作为使用者你只需要知道一件事模型对自然语言的理解精度直接决定了后续所有操作的上限。我实测下来同一个任务用不同的提示方式模型的理解准确率能差出三成以上。比如你说“帮我整理一下这份数据”模型大概率会反问你“整理成什么格式”。但如果你说“把这份 CSV 按日期列升序排列去掉重复行输出新的 CSV”它就能直接给你可执行的结果。这不是模型笨而是自然语言的模糊性天然存在。所以“会思考”阶段的一个关键经验就是你给模型的输入越结构化、越具体它的输出质量就越高。这个道理听起来简单但很多人在实际使用时会忽略。我见过不少朋友抱怨“AI 写的东西不能用”一问才知道他给的提示就一句话没有任何上下文和约束条件。这就好比你让一个新人帮你做事只说“把那个弄一下”人家当然不知道你要什么。2.2 推理能力的边界在哪里“会思考”的另一个重要维度是推理。现在的语言模型在逻辑推理、数学计算、代码生成这些任务上表现已经相当不错了但它有一个根本性的局限推理过程完全发生在“脑子”里没有跟外部世界交互的能力。什么意思呢举个例子。你问模型“今天天气怎么样”它只能根据训练数据给你一个泛泛的回答因为它没法实时去查天气接口。你让它“帮我把这段代码部署到服务器上”它只能告诉你部署步骤因为它没有服务器的访问权限。这就是“会思考”的天花板——它能告诉你“怎么做”但没法替你“做”。这个局限不是模型本身的问题而是架构决定的。语言模型的输入是文本输出也是文本它跟外部世界的唯一接口就是文字。要突破这个天花板就必须给它加上“手脚”让它能够调用外部工具、执行实际操作。这就是“能干活”阶段要解决的核心问题。2.3 从对话到指令交互范式的转变在“会思考”阶段我们跟 AI 的交互方式是对话。你一句我一句像聊天一样。但到了“能干活”阶段交互方式变成了指令。你给 AI 一个任务目标它自己去规划步骤、调用工具、执行操作最后给你一个结果。这个转变带来的第一个挑战就是任务描述的粒度怎么把握。太粗了AI 不知道从哪下手太细了那还不如自己干。我个人的经验是把任务拆到“一个可验证的子目标”这个粒度比较合适。比如“帮我订一张明天去某地的机票”这个任务可以拆成“查询明天某地航班的可用座位”“选择符合时间要求的航班”“填写乘机人信息”“完成支付”这几个子目标。每个子目标都有明确的完成标准AI 执行起来就不会跑偏。3. “能干活”阶段补齐执行能力的关键模块3.1 工具调用给 AI 装上“手”“能干活”的第一个关键模块是工具调用。所谓工具就是 AI 可以调用的外部函数或接口。比如搜索工具、计算工具、文件操作工具、API 调用工具等等。AI 根据任务需要自己决定调用哪个工具、传什么参数、怎么处理返回结果。工具调用的技术实现方式有好几种目前比较主流的是通过函数描述的方式把每个工具的功能、参数、返回值告诉模型模型在生成回复时如果判断需要调用工具就会输出一个结构化的调用请求。系统接收到这个请求后执行实际的操作再把结果返回给模型模型继续处理。我踩过的一个坑是工具描述写得太简略导致模型不知道该什么时候用。比如你定义了一个“搜索”工具描述只写“搜索信息”模型可能在任何需要信息的时候都去调它包括它自己已经知道答案的时候。后来我把描述改成“当需要获取实时信息或训练数据之外的信息时使用”调用准确率明显提升。所以工具描述一定要写清楚“什么时候用”和“什么时候不用”。3.2 任务规划让 AI 学会拆解步骤有了工具之后下一个问题就是AI 怎么知道该按什么顺序调用哪些工具这就是任务规划要解决的问题。任务规划的核心思路是让模型先把大目标拆成小步骤然后逐步执行。这个过程可以是线性的也可以带条件分支和循环。比如“帮我整理这份销售数据并生成报告”这个任务可以拆成“读取数据文件”“清洗数据”“计算统计指标”“生成图表”“撰写报告文本”“保存报告文件”这几个步骤。规划的质量直接决定了任务能不能跑通。我实测下来让模型在规划阶段多花点时间比让它急着执行要划算得多。具体做法是在提示里明确要求模型“先输出完整的执行计划确认无误后再逐步执行”。这样即使规划有问题也能在执行前发现避免跑到一半才发现方向错了。3.3 记忆管理别让 AI 干着干着就忘了多步骤任务有一个很容易被忽略的问题上下文长度。当任务步骤很多、每步返回的结果又很长时模型的上下文窗口很快就会被占满。一旦超出窗口限制前面的信息就丢了模型就会“失忆”。解决这个问题的思路是引入记忆管理机制。简单来说就是把任务执行过程中的关键信息提取出来存到一个外部存储里需要的时候再检索回来。这样模型不需要把所有信息都放在上下文里只需要保留当前步骤相关的部分。我在一个数据处理项目里用过这个方案。任务需要处理上百个文件每个文件的处理结果都要汇总。如果全部放在上下文里早就爆了。后来我把每个文件的处理结果存到一个字典里模型只需要知道“当前处理到第几个文件”和“汇总结果存在哪里”上下文占用一下子就降下来了。3.4 错误处理干活哪有不出错的让 AI 干活出错是常态。工具调用失败、返回结果不符合预期、任务规划有漏洞这些情况都会发生。关键是怎么处理。最基本的策略是重试。工具调用失败时让模型分析失败原因调整参数后重试。但重试不能无限进行一般设置两到三次就够了超过就说明这个方案本身有问题需要换思路。更高级的策略是让模型自己诊断问题。比如工具返回了一个错误信息模型需要判断这个错误是参数问题、权限问题还是网络问题然后采取不同的应对措施。这个能力需要模型有一定的推理能力目前主流的大模型在这方面表现已经不错了。我个人的经验是在任务规划阶段就把可能的失败情况考虑进去比执行阶段再补救要高效得多。比如在提示里加上“如果某个步骤连续失败两次尝试换一种方法如果换方法后仍然失败记录问题并跳过该步骤继续执行后续步骤”。这样即使中间有步骤卡住了整个任务也不会完全停摆。4. 一个完整“干活”链路的实操拆解4.1 场景设定自动整理会议纪要并分发为了把上面的理论讲清楚我拿一个具体的场景来拆解。假设你每周都要开项目例会会后需要整理会议纪要提取待办事项然后把待办分发给相关同事。这个任务涉及信息提取、文本生成、文件操作、消息发送等多个环节很适合用来演示“能干活”的完整链路。整个任务的输入是一段会议录音转写的文本输出是一份结构化的会议纪要加上分发给各责任人的待办通知。中间需要经过文本清洗、要点提取、待办识别、责任人匹配、纪要生成、文件保存、消息发送这几个步骤。4.2 步骤拆解与工具配置第一步是文本清洗。会议转写文本通常有很多口语化的重复、语气词和识别错误需要先做一轮预处理。这个步骤可以用一个简单的文本处理工具来完成主要是去掉无意义的填充词、修正明显的识别错误、按发言人或议题分段。第二步是要点提取。把清洗后的文本输入模型让它提取出讨论的主要议题、每个议题的结论、以及会上提到的待办事项。这一步的关键是提示的设计。我用的提示大概是这样的“请从以下会议记录中提取1讨论的议题列表2每个议题的结论3待办事项包括事项描述、责任人和截止时间。以 JSON 格式输出。”第三步是责任人匹配。待办事项里提到的责任人可能用的是昵称或简称需要跟通讯录里的正式姓名做匹配。这个步骤可以用一个简单的映射表来处理也可以用模型来做模糊匹配。第四步是纪要生成。把前面提取的信息组织成一份格式规范的会议纪要包括会议时间、参会人员、议题讨论、结论、待办事项等部分。第五步是文件保存和消息发送。把纪要保存为指定格式的文件然后根据待办事项的责任人给每个人发送对应的待办通知。4.3 关键参数与配置说明在这个链路里有几个参数需要特别注意。第一个是模型的温度参数。温度控制输出的随机性温度越高输出越多样温度越低输出越确定。对于会议纪要这种需要准确提取信息的任务温度建议设低一些我一般用 0.1 到 0.3 之间。温度太高的话模型可能会“脑补”一些会上没说的内容。第二个是最大输出长度。会议纪要通常比较长如果最大输出长度设得太短模型可能会在写到一半的时候被截断。我一般会根据会议时长来估算一小时的会议大概需要 2000 到 3000 个 token 的输出长度。第三个是重试次数。对于工具调用类的操作比如文件保存和消息发送建议设置两到三次重试。但要注意重试的时候要确保操作是幂等的避免重复发送消息或重复保存文件。4.4 执行流程与中间结果验证整个执行流程可以串行也可以并行。文本清洗和要点提取必须串行因为后者依赖前者的输出。但待办事项的分发可以并行每个责任人的通知可以同时发送。中间结果的验证很重要。我一般会在每个关键步骤后面加一个校验环节。比如要点提取完成后让模型自己检查一遍“提取的待办事项是否都有责任人和截止时间”如果有缺失就补上。这个自检环节看起来多余但实际能拦住不少问题。还有一个经验是把中间结果保存下来。万一后面某一步出了问题不需要从头重跑直接从出问题的步骤开始就行。这在调试阶段特别有用能省不少时间。5. 常见问题与排查技巧实录5.1 工具调用失败的高频原因工具调用失败是最常见的问题原因通常有这么几类。第一类是参数格式不对比如该传字符串的地方传了数字该传数组的地方传了单个值。这类问题一般看错误信息就能定位修正参数格式即可。第二类是权限问题比如调用的接口需要认证但没传 token或者 token 过期了。这类问题需要检查认证配置确保 token 有效。第三类是网络问题比如接口超时或返回了非预期的状态码。这类问题可以通过重试来解决但如果频繁出现就需要检查网络环境或接口的稳定性。第四类是工具描述不清晰导致模型调用错误。比如有两个功能相似的工具模型分不清该用哪个。解决办法是在工具描述里明确区分两者的使用场景。5.2 任务跑偏的排查思路任务跑偏的表现是AI 执行的结果跟你的预期不一致但又说不出哪里错了。这种情况通常是因为任务描述有歧义或者中间某个步骤的输出被模型误解了。排查的思路是回溯。把每个步骤的输入和输出都打印出来看看是从哪一步开始偏离预期的。如果是任务描述的问题就补充约束条件如果是中间步骤的问题就调整那个步骤的提示或工具配置。我遇到过一个典型案例让 AI 整理一份客户反馈列表结果它把反馈按情绪分类了而我的本意是按产品模块分类。问题出在提示里只说了“整理反馈”没有明确分类维度。后来改成“按产品模块分类整理客户反馈”结果就对了。5.3 上下文超限的应对策略上下文超限的表现是任务执行到一半模型突然开始“胡言乱语”或者重复之前的内容。这是因为上下文窗口被占满模型丢失了前面的信息。应对策略有三个层次。最直接的是压缩上下文把不必要的信息删掉只保留当前步骤相关的部分。其次是引入外部记忆把关键信息存到外部存储需要时再检索。最后是拆分任务把一个大任务拆成多个小任务每个小任务独立执行最后汇总结果。我一般优先用第一种因为实现简单。如果压缩后还是超限再考虑后面两种。拆分任务虽然麻烦但效果最彻底适合处理特别复杂的场景。5.4 常见问题速查表问题表现可能原因排查方法解决思路工具调用返回错误参数格式不对检查错误信息和参数定义修正参数格式工具调用无响应网络超时或权限问题检查网络和认证配置重试或更新认证信息任务执行到一半停止上下文超限查看上下文占用情况压缩上下文或拆分任务输出结果不符合预期任务描述有歧义回溯各步骤输入输出补充约束条件模型反复调用同一工具工具描述不清晰检查工具描述明确工具使用场景待办事项遗漏提取提示不完整检查提取结果增加自检环节6. 从单次执行到稳定交付工程化落地的几个关键点6.1 可观测性让每一步都看得见把 AI 干活的能力用到实际项目里光跑通一次是不够的还得保证每次都能稳定跑通。这就需要有足够的可观测性能随时看到任务执行到了哪一步、每步的输入输出是什么、有没有异常。我的做法是在每个关键节点打日志记录时间戳、步骤名称、输入摘要、输出摘要、耗时、状态。这样出问题的时候翻日志就能快速定位。日志的粒度要适中太粗了看不出问题太细了日志量太大。我一般按“一个可验证的子目标”来打日志每个子目标一条记录。除了日志还可以加一些监控指标比如任务成功率、平均执行时长、工具调用失败率等。这些指标能帮你发现一些隐性问题比如某个工具的成功率在缓慢下降可能是接口稳定性出了问题。6.2 幂等性重复执行不出错任务执行过程中难免会遇到需要重试的情况这时候幂等性就很重要了。所谓幂等就是同一个操作执行多次结果跟执行一次是一样的。对于文件操作幂等性相对好保证比如保存文件时用覆盖模式而不是追加模式。对于消息发送幂等性就需要额外处理比如给每条消息生成一个唯一 ID发送前先检查这个 ID 是否已经发送过。我在一个通知分发项目里就遇到过这个问题。任务重试的时候有些同事收到了重复的通知。后来加了一个发送记录表每次发送前先查一下这个待办是否已经通知过该责任人问题就解决了。6.3 人工兜底该出手时就出手不管 AI 多能干总有一些情况是它处理不了的。这时候就需要人工兜底。常见的做法是设置一个“人工审核”环节当 AI 对某个步骤的置信度低于阈值时暂停执行等待人工确认。置信度可以从几个维度来判断模型对输出结果的自我评估、工具调用的返回状态、历史执行的成功率等。我一般会设置一个简单的规则如果某个步骤连续失败两次或者模型明确表示“不确定”就触发人工审核。人工审核的界面不需要太复杂把当前步骤的输入输出展示出来让审核人选择“继续”“修改后继续”或“终止”就行。关键是审核的响应要快不能卡住整个流程。6.4 持续优化从每次执行中学习每次任务执行都是一次学习机会。成功的案例可以沉淀为模板失败的案例可以转化为改进点。我习惯在项目里维护一个“案例库”记录每次执行的情况和对应的处理方式。比如某个提示词效果特别好就把它存下来下次类似任务直接复用。某个工具调用经常出问题就记录下来看看是工具本身的问题还是使用方式的问题。时间长了这个案例库就成了项目的知识资产新来的同事也能快速上手。7. 我个人的一些实操体会从“会思考”到“能干活”这个跃迁说起来简单做起来涉及的细节非常多。我最大的体会是不要试图一步到位。很多人一开始就想做一个全自动的复杂 Agent结果卡在某个环节就进行不下去了。更好的做法是从一个简单的单步任务开始跑通之后再逐步增加步骤和工具每一步都验证通过再往下走。另一个体会是提示词的质量比模型的选型更重要。我试过用同一个模型换一套更好的提示词任务成功率能从六成提升到九成以上。所以与其花时间比较不同模型的参数不如先把提示词打磨好。还有一个容易被忽略的点是错误处理的设计要前置。不要等到出了问题再想怎么处理而是在设计任务流程的时候就把可能的失败情况考虑进去。这样即使某个步骤出了问题整个任务也不会完全崩溃。最后分享一个小技巧在任务执行的关键节点加上“自检”环节让模型自己检查一下输出是否符合要求。这个自检不需要太复杂就是让模型回答“我刚刚生成的待办事项是否都包含了责任人和截止时间”这类问题。实测下来这个简单的自检能拦住不少低级错误性价比很高。