大模型不是万能计算器：模型理解、专业工具计算、人做决定

为什么不能让模型自己算

企业常常希望“一句话出报告”。但很多业务计算有明确规则：选址要做空间叠加分析，装车要做三维装箱，包装要按标准换算营养成分。既然专业软件或算法能精确计算，就没有必要让大模型自己去算，它也未必算得准。

更合理的分工是：模型负责理解和分析，专业工具负责事实和计算，人负责最终决策。

一种常见的分工结构

• 模型：理解意图、从图片和文档中抽取信息、组织语言、解释结果；
• 工具和代码：计算、检索事实、执行固定规则；
• 人：判断、取舍、签字负责。

以食品包装审核为例：包装图上有密集文字、营养成分表和艺术字，单靠模型看图并不可靠。可以把包装拆成不同区域，分别用合适的识别方式处理；营养成分的计算固化成确定性代码，模型只负责解释和提出补充建议。每个结论都标注来源和可信程度，审核人员就知道该信什么、该查什么。

不是每个问题都需要智能体

规则非常确定的任务，写一个脚本、跑一个定时任务就够了；只有涉及语义理解和跨系统判断、传统脚本难以覆盖时，才值得引入智能体。

“多个智能体互相讨论”听起来先进，但如果问题最终依赖明确的规则和指标，多个智能体之间来回传递上下文，反而可能带来歧义和信息丢失。更稳妥的做法是把不同专业能力封装成工具，由一个核心流程统一调度。某些求最优解的问题，传统优化算法往往比大模型更准确。

报价类问题也常常是混合方案：一部分靠模型理解客户需求，一部分靠业务规则，还有一部分是成本和路线的计算。

稳定性要靠系统设计

“模型本来就不确定，所以答案不同很正常”这种说法，企业很难接受。数据不变时，同一个问题应得到同样的结论。可以把分析过程拆成细的步骤，规定每一步的方法和输出结构，并用同一组问题反复测试结果是否一致，同时关注调试和运行成本。

远行者科技的做法

WorkBuddy 能调用哪些工具、连接哪些系统，以腾讯官方说明和企业实际环境为准。在应用实施中，我们会先把任务中的计算和规则部分单独列出，确认由哪个工具或表格承担，再设计模型参与的环节。