千问实战：从Function Calling到Agent，AI如何真正“干活”？

前两年我们夸一个大模型，说它“真能聊”，基本就是最高评价了。现在风向变了。最近一阵子，我观察到的现象是，包括千问在内的主流大模型，越来越强调“干活”而不是“对话”——它们开始调用工具、操作文件、跑流程，甚至替你把一件完整的事办完。这个转变，比参数数字更值得关注。

如果你还停留在把AI当问答框用的阶段，那你大概率会错过这一波真正的红利。这篇文章我想聊的，就是“千问开始干活”背后到底发生了什么、实测下来有哪些真实体验、以及不同角色的人该怎么抓住这个机会。无论你是开发者、产品经理，还是单纯想用AI提升效率的上班族，这篇内容都值得看完。

1. 为什么说“能干活”才是AI的分水岭

1.1 对话解决“知道”的问题，干活解决“做到”的问题

聊天式AI的边界其实很清晰：你问它一个问题，它给你一段文字。内容再精彩，信息的闭环仍然停留在屏幕里。它像一个很博学的朋友，能告诉你很多道理，但没法替你跑腿。

“干活”则完全不同。当AI开始调用工具、读写文件、操作系统接口的时候，它的输出就从“建议”变成了“动作”。同样是处理一份周报：对话式AI只能帮你起草文字，而“干活”式AI可以把日报、周报、Excel表格全部拉出来，自动汇总成PPT，再按名单发出去。前者省的是“想的时间”，后者省的是“做的时间”，价值量级完全不在一个层次。

1.2 从“工具人”到“实习生”的角色变化

我特别喜欢用一个类比：过去我们用AI，像是翻一本会说话的百科全书；现在用AI，更像是带一个刚入职的实习生。实习生不一定每件事都做得完美，但你确实可以把一件相对完整的事交代给他，让他去查资料、填表格、跑流程，最后给你一个能用的结果。

这个角色变化带来的是整个人机关系的重构。以前我们是“提问者”，靠自己的判断去筛选信息；现在我们是“任务分配者”，要学习的是怎么把目标讲清楚、怎么设置检查点、怎么验收成果。门槛没有消失，只是换了位置。千问这类模型开始强调工具调用和任务执行，本质上就是把自己从“知识库”改造成“执行体”，这才是分水岭所在。

2. “干活”背后到底发生了哪些技术变化

2.1 Function Calling：模型学会了写“申请单”

AI能“动手”的第一步，是模型学会了输出结构化的调用指令。过去模型只会输出纯文本，告诉用户“你可以去查一下天气”，现在它能直接在回复里附带一个请求：调用某个接口，传入城市参数，拿到结果之后再组织语言回复。

行业内管这个叫Function Calling（函数调用）。名字听着高大上，其实特别好懂：模型不再只是“说”做什么，而是会“写单子”——把“我要调用什么功能、传入什么参数”用固定格式写清楚，由外部系统去真正执行。这就好比实习生学会了填写“采购申请单”，虽然他本人不直接付款，但整套流程因为他能填单子而跑通了。

2.2 Agent框架：从单次调用变成循环执行

光有一次调用还不够。真正“干活”的场景里，往往是一个任务需要拆成很多步：先读文件、再查数据、然后对比、最后生成报告。这一步的结果可能要作为下一步的输入，中间做错了还可能要回头调整。

这就催生了Agent（智能体）的工作模式。一个基本的Agent循环大致是：规划目标、选择工具、执行动作、观察结果、修正计划、再执行……直到任务完成。这个循环在过去很难实现，核心瓶颈是模型能力不够——走着走着就忘了目标，或者一遇到异常就不知道怎么办。当模型本身的推理和规划能力上来了，这个循环才真正转得动，千问能“干活”的背后，本质上是这个循环的稳定性达到了可用水平。

2.3 上下文变长和工具生态的成熟

除了模型本身的进步，两个外部条件也很关键。

首先是上下文长度。一个任务往往伴随大量背景材料，比如几十页文档、若干份表格，如果模型记不住前面的内容，后面就没法连贯执行。长上下文让AI第一次能“带着一摞材料干活”而不是“聊一句忘一句”。

其次是工具生态。真正让模型“有手可用”的，是越来越多的软件开始开放接口：表格软件能写入了、项目管理工具能建任务了、浏览器能自动操作了。外部世界的API越丰富，AI能“干”的活就越多。这是生态问题，不是单靠一个模型能解决的。

2.4 多模态是中间的桥梁

另外要注意，多模态能力在“干活”里扮演的角色被很多人低估了。实际任务里，输入往往不只有文字：可能是截一张图让你看报错信息，可能是拍一张白板让你整理会议纪要，也可能是口述一段需求让你生成一份文档。多模态让AI能“看懂”现场，而不仅仅是“听懂”问题。从看、到理解、再到动手做，这才是一条完整的链路。

3. 用千问实际干一次活的完整记录

3.1 任务设计：整理混乱项目资料并产出结构化文档

光说原理可能有点虚，我拿自己的一次实测来拆解。某个模拟项目X积累了大量半成品资料：十几份命名混乱的文档、多个版本的Excel、零散的代码注释和PPT大纲。我的目标是，让千问帮我通读这些材料，产出一份结构化的项目状态说明，列出已完成事项、待办清单和风险点。

这个任务的关键在于它不是一个“回答型”任务，而是“整理型”任务——需要读多个文件、跨材料比对、识别重复内容，还要按照一定结构重新组织输出。整个过程本身就是一次小型的“Agent式干活”。

3.2 执行过程的几个关键节点

我把文件放在一个统一目录下，然后给AI下了明确的指令：读取目录内所有文档，先输出每个文件的主题摘要，再交叉比对找出重叠和遗漏，最后生成一份汇总文档。

实测中几个节点印象很深。第一步读取文件很顺利，AI能识别多种格式，甚至能从PPT大纲里提取层级关系；第二步归纳时它提出了一个我没想到的分类方式，按“已完成/进行中/存疑”而不是单纯按文档类型分；但第三步也暴露了问题——它对一些基本废弃的旧版本文件投入了过多注意力，反复在总结里提到早已被取代的信息，需要我额外指定“只看最新版本”的规则才纠正过来。

3.3 好用的地方和翻车的地方

我把这次实测的感受整理成了表格：

整体感受是：它确实能“干活”，但离“放心的干活”还有距离。最舒服的使用方式是把它当“强力初稿生成器”——让AI完成80%的整理工作，我专注在剩下20%的判断和决策上。

4. 干活型AI必须提前防住的四个坑

4.1 幻觉从“误导”升级成“破坏”

聊天时代，模型胡编一个典故，最多让你丢面子；干活时代，如果模型幻觉式地以为某个文件已经删过了、或者某个接口参数应该这样传，造成的影响就是实打实的损失了。这个问题在Agent场景被放大了无数倍。我在实测时发现，将幻觉内容直接写入到最终文档的情况偶尔出现，如果不检查就发出去了，全组人都会跟着踩坑。解决办法没有捷径：高危输出必须加人工确认，重要数据要留审计痕迹。

4.2 权限和安全的边界必须提前画好

给AI“干活”的权限时，很多人下意识会给最大权限，这是最危险的。在一个Agent系统里，模型能调用的工具越多、权限越大，出错和失控的半径就越大。一个最基本的底线是“最小权限”：能让它只读的就不给写，能让它操作沙箱的就不碰生产环境，能加人工审批的就不走全自动。宁可牺牲一点效率，也不能把关键系统的钥匙直接交出去。尤其是涉及到删除、发送、支付这类不可逆操作，强烈建议加一道人工闸门。

4.3 多步任务的不收敛问题

Agent在执行长任务时有个常见毛病：绕圈。比如在整理文档时，它会反复重新读取同一个文件、重复优化同一段内容，或者在一个分支问题上越挖越深，忘了最初的目标。专业做法是在系统层面设置“最大步数”和“终止条件”，同时在Prompt里明确写出完成标准。我自己的习惯是：每一步执行完都输出一个简短的中间状态，让我能看到它正在干什么，而不是等它跑完自动出结果。没有中间状态可视化的Agent，基本等于盲盒。

4.4 评测体系还没有跟上

对话式AI好不好用，聊几句就知道；干活型AI好不好用，需要一套新指标。传统的“回答正确率”不再适用，我们更关心的是：任务完成率有多高、人工介入率有多高、平均成本是多少、出了错能不能追溯。如果你后面打算把Agent接入业务，建议从一开始就建立一个小型测试集，把高频场景固化成评测任务，每次改动都跑一遍，防止“这儿修好了、那儿又坏了”的连锁问题。

5. 机会到底在哪里：从“会聊天”到“会干活”

5.1 开发者的机会：做Agent的“脚手架”

对开发者来说，这波最大的机会不在模型本身，而在模型之外的工程配套。Agent跑起来之后，你会立刻发现缺一堆东西：可复用的工具封装库、任务编排流程、状态可视化界面、成本监控和失败重试机制、测评回归集。这些“脚手架”类的工作，通用性极强，且远比重新训练一个大模型更接近落地场景。我身边很多团队现在的状态是：模型能力够了，但工程底座还是手工搭的，谁先把底座做好，谁就掌握了主动权。

5.2 产品经理和业务方的机会：流程再造

对产品和业务端，最值得做的一件事是重新审视现有工作流：有哪些环节是“规则明确、重复度高、数字化程度高”的？这些就是最适合Agent化的对象。比如客服工单分类、数据报表汇总、竞品信息收集、审批材料预审，都是典型的“看起来需要人，实际上全是重复劳动”的活。值得留意的是，优先级要从“最痛的”而不是“最简单的”开始切。第一个Agent项目如果能帮团队省下一周2天的人力，后续推广的阻力会小非常多。

5.3 普通从业者的机会：先给自己配个“数字助理”

即便你不写一行代码，这波机会同样有参与方式。最实在的切入点是：找出一件自己每周都要做、且特别机械的重复事，想办法交给AI。比如每周整理项目周报、每天归档邮件附件、定期汇总几个网站的公开数据。不要一上来就想搭建一个完美系统，先用平台或现成工具跑通一个最小的流程，感受一下“把活交给AI”是怎样的协作方式。你在过程中积累的对任务的拆解能力，就是未来几年最吃香的技能。

6. 现在就能动手的三条路径

6.1 路径一：从给AI接一个“函数”开始

最快的上手方式，是体验一把Function Calling的完整闭环。选一个小场景，比如“根据用户提问查询订单状态”或“根据城市名获取天气信息”，把查询能力封装成一个接口，让AI在回答问题时自动调用它。用大白话说，就是教AI“不会的时候别瞎编，去查一下再说”。这个实验规模小、成本低，但能让你直观理解“模型输出指令、系统执行动作”这一核心机制。

6.2 路径二：搭一个最小Agent工作流

跑通函数调用后，可以试着搭一个最小的Agent循环。参考这个模板：

• 目标设定：用一句话讲清楚最终要交付什么（比如“把content目录下的文档整理成一份带索引的报告”）。
• 工具准备：明确AI可以用哪些工具（读文件、写文件、查表格），没有的工具先封装。
• 执行与检查：每完成一步，让AI输出进度摘要，人工判断是否继续或修正。
• 结果输出：最终结果先进入“草稿区”，人工确认后再投入使用。

这个流程虽然简陋，但是已经具备了一个Agent的基本框架。跑通一次之后，你会对“什么是可控的自动化”有非常具体的体感。

6.3 路径三：利用现成的Agent框架和平台

现在有很多现成的Agent编排框架和可视化平台，支持把多个模型、工具串成一个工作流。我的建议是：不要重复造轮子，也不要用太复杂的平台一上来就追求全自动。先拿现成框架把上面那个“最小工作流”复现一遍，重点理解里面每个节点的输入输出是怎么衔接的，踩过一次“A节点的输出格式B节点解析不了”的坑之后，你对Agent的理解会完全不一样。

最后聊点我的实际体会

实验做过几轮之后，我最大的感受是：别急着追求全自动，先把一个小闭环跑通。很多人看到“AI能干活”就兴奋地想一步到位，结果被复杂的权限、容错、流程问题淹没，最后又退回纯聊天模式，这是最可惜的。真正务实的做法是给AI配一个“人类确认”的环节，把它用在那些“你不做也行、但做了更好”的重复流程里。还是那句话，AI帮你把活干到80%，剩下的20%关键判断留给你，这在很长一段时间里，可能都是最有性价比的协作方式。