智能体Agent是怎么接住大模型消息的

2026-09-23 · 上海临境绘谷信息科技有限公司

上个月，一家做工业配件的客户给我们看了一张截图。同一个问题，同一个智能体，一次 4 秒返回，另一次 41 秒。

我把两次的会话追踪调出来并排看，原因很朴素：快的那次，它跟模型来回跑了两趟；慢的那次跑了十一趟，其中七趟是同一个查询工具在换着仓库名反复试。

客户问的是性能，我更想让他看另一件事：那十一趟里，每一趟都在传什么。

大多数人对智能体的想象是这样的：把任务“发给”模型，模型“返回”结果，智能体“执行”。听起来像三方通话。实际过程跟通话一点关系都没有。模型不接电话，它只是一遍遍读你递进去的一叠纸。

这一篇只讲那叠纸。前面两篇讲过的两件事这里直接当结论用：模型只会一个字一个字往外吐，它没有手；一个能干活儿的智能体得看得见现场、能一轮一轮推、能真的动手、知道什么时候停、知道自己的边界在哪。至于这份委托怎么成立、需要配齐哪几样，那是上一篇的内容，这里不重复。

一分钟速览

• 智能体和大模型之间不存在“通信”。 每一轮的形态都是同一件事：智能体把当前所有材料组装成一条请求递进去，模型吐一段文字出来。模型不记得上一轮，也看不到你的系统。
• 一次工具调用是三条消息，不是一条。 递材料 → 模型吐回一张填好的调用表单 → 智能体执行完，把结果连同原来的全部材料再递一遍。
• 模型吐回来的表单是建议，不是命令。 里面的参数是它猜出来的，不是读出来的。校验、鉴权、执行、留痕，全部发生在智能体这一侧。
• 每一轮都要把前面的全部内容重发一次。 这一条决定了 token 账单大致按轮数的平方往上走，也决定了长任务为什么又慢又贵。
• 模釜（AgentSteamer） 是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，支持完整私有化部署，且不绑定特定大模型。

一、一次真实的往返：三条消息（Agent Loop）

先立一个最小的例子，后面所有内容都围着它转。

用户在智能体里问了一句：A-1024 在华东仓还有多少件？

这个问题答得完，智能体和模型之间要走三轮。注意是三轮，不是一轮。

第一条：智能体递给模型的材料包

这条请求是智能体拼出来的，不是用户写的。它大概包含四样东西。

• 系统提示词：你是华东区的库存助手。查询只能调用 query_stock 这个工具。仓库名要用全称。查不到就直说查不到，不许估算数字。
• 工具清单：query_stock —— 查询指定仓库里某个货号的库存量。参数 item_code（货号，字符串，必填）、warehouse（仓库名，字符串，必填）。还有一个查仓库列表的 list_warehouses。
• 历史：这个会话之前说过的话、之前所有工具返回过的结果，全都在这儿。
• 这一轮的输入：用户刚打的那句话。

四条里只有最后一条是用户写的。其余三条都是智能体自己组装进去的，用户看不见。

第二条：模型吐回来的那段结构化内容

模型读完之后，吐出来的不是“好的，我这就帮您查”，而是一段人看着不像话的文字。它的意思是：

• 要调用的工具：query_stock
• 参数：item_code 是 A-1024，warehouse 是 华东仓
• 一个编号：call_7f3a91，用来给这张单子对号

这段文字的格式是有约定的，业界一般用 JSON 这种写法，字段名是固定那几个。模型并不“知道”自己在调用什么，它只是把这段文字写得符合约定，然后吐出来。

第三条：智能体执行完，再递一次

智能体接住这段文字，解析出工具名和参数，去真正查询，拿到结果 46。

然后它做了一件容易被忽略的事：把第一条里的东西原封不动再发一遍，末尾追加一条：call_7f3a91 的执行结果是 46。

模型这才看到“46”这个数字，于是有依据说出那句人话：A-1024 在华东仓还有 46 件。

这三条消息是什么关系

它们不是一段对话的三句，是三次独立的完整请求。第二、第三条都要把前面的内容重新带上一遍，因为模型没有记忆，每一轮它都是重新把整张桌子读一遍。

那个 4 秒变 41 秒的例子，就出在这一圈一圈里：如果模型第一次把仓库名填成了“华东”，工具返回“仓库不存在”，它会收到这条错误，然后换一个填法再试。试对了是好事，试不对就一直在试。

二、第一条消息：智能体递给模型的提示词（System Prompt 与 Tools）

这一条是整件事的地基，也是最容易被糊弄过去的地方。它里面有两个部分值得单独说。

系统提示词：这批活的规矩

系统提示词是智能体在每一轮都固定带上的那段说明。它管的是模型这一轮扮演谁、能干什么、不能干什么、按什么格式作答。

上面那个例子里，三句话定死了三件事：身份（华东区库存助手）、可用手段（只能调 query_stock）、以及一条兜底规则（查不到就说查不到，不许估算）。

最后那条兜底规则，比前两条都值钱。 回想第一篇里讲过的：模型写“查询结果”的能力和写“查询请求”的能力是同一套能力。没有这条规矩，它在工具返回空的时候完全可能顺手编一个数字出来，而且编得格式正确、语气笃定。

反过来说，系统提示词写歪了，后果是全局的。它每一轮都在场，一句话措辞上的含糊会在几百次调用里被放大几百遍。

工具清单：给模型的那本菜单

工具清单是请求里一个独立的部分，不需要模型去“发现”。里面每一项至少要有三样东西：名字、描述、参数说明。

参数说明的写法有个约定叫 JSON Schema，说白了就是给每个参数标上类型、是否必填、取值范围、格式示例。名字叫 date 的参数如果不写清楚格式是 2026-09-23 还是 20260923，模型就只能猜，而它猜错的概率高得超乎想象。

第一篇里那个比喻在这儿最贴切：这是递给它的一本菜单。菜单上没有的菜点不出来，菜单上写得含糊的它只能瞎猜。

这里有个企业里常被忽略的点：工具的数量本身也是成本。 一次塞五十个工具的清单，模型选错的概率会明显上升，而且这份清单每一轮都要重发一遍。真实项目里更常见的做法是先给一份目录，让它按需展开，而不是一次性摊开。

剩下的部分：现场

系统提示词和工具清单之外，第一条消息里还装着这一轮的“现场”：用户这句话、之前的对话、从知识库里检出来的相关片段、以及这一轮真正需要的业务数据。

这里有个原则值得记住：现场不是装得越多越好。 桌子就这么大，材料堆太多，它反而会漏掉夹在中间的部分。往桌上摆什么、按什么顺序摆、摆不下时先撤哪一份，是设计出来的，不是自动形成的。

> 判断方法：把你在用的那个智能体的系统提示词原文导出读一遍。如果里面只有“你是一个专业的助手”这类话，没有一条能约束它在查不到数据时怎么办的规则，那这个智能体是在靠运气工作。

三、第二条消息：模型吐回来的不是命令，是一张填好的表单（Tool Calls）

这一段是整篇里最容易误解的地方，我拆细一点。

它吐回来的东西长什么样

模型决定要查库存时，输出里会出现一个专门的字段，这个字段里装着它想调用的工具名和参数。同时还会带一个编号，上面例子里是 call_7f3a91，作用是让后面返回的结果知道自己是给哪张单子的回执。

有两个工程细节值得知道：

一是可以一次填好几张单子。 模型在一条消息里返回多个工具调用是允许的，比如同时查两个货号。这看起来是效率提升，但它同时意味着你的执行层要有并发控制，两条互相关联的写操作同时发出去，后果可能很麻烦。

二是参数是猜出来的。 这一点再怎么强调都不过分。模型填参数的过程，和它写“今天天气真好”是同一个过程，都是预测下一个词。

后果就是它在参数上犯错的方式非常“人性化”：日期格式来回变、编号大小写混着写、金额单位自己给加上去、字段名看着像就填、需要编号的地方直接编一个看起来合理的编号。它不是在读你数据库里的值，它是在写一段看起来像真的文字。

上面那个 41 秒的例子，源头就可能是这里：仓库名它填了“华东”，接口要求的是“华东仓”。

智能体接住之后，先做三件事，再谈执行

表单到手，一个稳健的智能体不会直接照做。中间至少还有三道：

• 结构校验：参数名对不对、类型对不对、必填的有没有缺。缺了一个必填参数就发出去，等于把接口的错误码当成了业务答案。
• 取值校验：这个货号存不存在、这个仓库你有没有权限看、金额是不是在合理区间。注意这一层要跟上一层的权限分开看：模型知道有个查询工具，不代表这一轮的提问者有权看这个仓库的数据。工具清单是给模型看的，权限判定是给发起人做的，两者不能混为一谈。
• 危险动作拦截：查询类工具出错最多是没查到，写操作类工具出错就是真改了数据。删文件、发邮件、提交表单这类动作，应该在执行层就把“谁能触发、需不需要人工点头”定死，而不是指望模型自己拿捏。

> 判断方法：挑一个模型填的参数，故意改成一个合法类型但不存在的值（比如把一个不存在的货号填进去），看系统返回什么。如果它返回的是一句编排好的业务话术，说明中间有校验层；如果它把接口的原始错误码原样吐给了模型，那就等于把这段错误信息当线索喂给了模型，它接下来很可能会开始猜。

四、第三条消息：执行完，把结果连同前面的全部内容再递一次（Tool Result）

工具真跑完了，结果怎么回到模型面前，这一步的讲究不比前面少。

回执要挂对号

返回给模型的结果不是随便一段文本，它是一条带标记的消息，标记里要写清楚是给哪张单子的回执（上面那个 call_7f3a91）。同一轮里如果模型填了好几张单子，这几条回执各挂各的号，模型才知道哪条结果对应哪个问题。

这个设计看起来啰嗦，但它解决的是一个很实际的麻烦：一旦对错号，模型会拿着 A 仓库的数字去回答 B 仓库的问题，而且它自己不会觉得哪里不对。

回灌之前，结果通常要被剪一遍

这是企业里被低估最多的一件事。

假设那个库存查询工具返回的是一张两百行的表格，所有仓库所有货号都列上了。这段内容会塞进模型的上下文里，然后在接下来的每一轮里都要重发一遍。

于是就有了三个后果：这一轮变贵，后面每一轮都变贵，而且塞在中间的那几行它多半会漏掉。

所以真实系统里，工具返回的内容几乎都是被打磨过的：只留相关的那几列、长文本先截断、列表先聚合成一句概况。工具返回什么，不是接口决定，是设计决定的。 这一步做没做，直接决定这个智能体能不能跑长任务。

然后，整个材料包重发一遍

这是第一条消息的重复，但要多说一句为什么。

模型没有记忆。它看到 46 这个数字，是因为这一轮智能体把“问题 + 表单 + 回执”一起递了进去。上一轮它看到的桌子，这一轮要重新摆一次，摆的时候还会多铺一层。

用账面上的话讲：第 N 轮递进去的，是前三轮累计的全部内容。一个转十圈的任务，token 消耗大致是按圈数的平方往上走的。Agent 的花费和耗时，通常不是被“想”掉的，是被“来回跑”掉的。 这句话上一篇里说过，原因就落在这一节。

出错的时候，错误也是要回灌的

工具执行失败，不是一个内部异常就完事。这段失败信息会作为回执回到模型面前，然后它据此决定下一步：换个参数再试、换个工具、还是停下来问人。

这里有个分寸要拿捏。错误信息写得越像线索，模型越倾向于自己接着试；写得越干脆，它越容易停下来。 一个返回“操作失败”的工具和一个返回“仓库名不存在，可选值为：华东仓、华南仓”的工具，会把模型引向完全不同的两种行为。

> 判断方法：找一个查不到数据的场景，看智能体停下来问人，还是一直在换参数重试。如果它转了很多圈才停，去看工具返回的错误信息是不是给得太“友善”了。

五、这笔账怎么算：轮数、成本与失败（Token 与延迟）

三条消息讲完，可以算一算总体账了。这张账本有三个科目。

钱。 计价按 token 走，而每一轮都要把前面的内容重发一遍，所以总消耗随轮数快速上升。同样一件事，转两圈和转十一圈，账单能差出十几倍。这不是模型的问题，是循环结构本身的属性。

时间。 每一轮都要等模型把内容一个个吐出来，通常还要等工具执行。一次任务 4 秒还是 41 秒，主要取决于转了几圈，跟模型单轮快慢关系反而没那么大。

可靠性。 每一轮都是一次可以出错的环节：模型可能填错参数，工具可能超时，网络可能断，接口可能返回了格式不对的内容。圈数越多，出错的概率是累加的。那个 41 秒的例子里，最后之所以慢，是因为其中一圈的错误没有被干脆地识别出来。

一个转十圈以上的任务，在这三个科目上都会明显吃紧。所以企业里真正在做的工夫，大半花在减少圈数和让每一圈更结实上，而不是花在换一个更强的模型上。

六、企业里真正难的地方：稳健运行要管住哪几件事

前面几篇里讲过一个能干活儿的智能体需要配齐哪五样东西：看得见现场、能一轮一轮推、能真的动手、知道什么时候停、知道自己的边界在哪。那是从概念上说的。

这一节说的是同一批事情落到报文上之后，会变成哪几件具体的活。我按在我们自己平台里踩过的顺序排。

1. 模型填的表是建议，不是指令

这条是前面几节的自然结论，但它在企业里经常被跳过。很多团队接工具的做法是：拿到模型给的参数，拼成请求，发出去。这相当于把模型的猜测直接送进了业务系统。

正确的分层是：模型只负责提出意图，参数的合法性、发起人有没有权限、这个动作要不要走审批，全部在执行层判定。模型可以建议调用删库接口，但它建议了不等于它能调用成。

> 判断方法：拿一份你们智能体上周的调用记录，随机挑三条，问一句话：这三个动作分别是谁授权发起的？答不上来，说明授权是在模型那一层默认给全了的。

2. 同一件事不能真的干两遍

模型超时会重发，网络抖动会重连，用户会不耐烦地再点一次。提交订单、发通知、扣额度这类动作，必须有办法识别出“这一单我已经处理过了”。 做法上通常是给每次调用带一个唯一的业务标识，重复的请求直接返回上一次的结果。

这一条在只读工具上看不出重要性，等接了写操作的工具，它就是一个事故开关。

> 判断方法：看你们的工具清单里，有几个是“改了数据就回不去”的。这几个里面，有几个带了防重复的机制。第二个数字如果明显小于第一个，这就是你下一个事故的位置。

3. 每一轮都得有个天花板

一个没有上限的循环，真实世界里最常见的表现不是答错，是卡在某一步反复重试，一圈一圈地烧，直到有人发现账单不对。

上限要设成硬性的，而且是好几条一起设：最多跑几圈、最多花多少 token、最多跑多久、同一个工具最多重试几次。碰到天花板就停下来交给人，哪怕任务没做完。承认它没做完，比让它自己想办法凑出一个答案安全得多。

> 判断方法：找一个你们内部测试用的智能体，故意给它一个查不到的数据，然后别管它。看它转多少圈会停。如果它不吃不喝转了二十分钟还在试，那这个上限只存在于文档里。

4. 工具返回的东西要剪过再回灌

第四节讲过原因，这里补一句企业视角：工具的返回格式，是一项需要有人负责的设计资产。

同一个数据库查询，可以返回一张两百行的原始表，也可以返回一句“华东仓 A-1024 剩余 46 件，为三个仓库中最低”。前者让模型便宜不了、也准不了，后者才让这个智能体转得动长任务。

这件事往往没人负责：接工具的人只关心跑通，做提示词的人不知道工具返回了什么，最后结果是原始数据一坨坨灌进上下文。

> 判断方法：找一次长会话，把中间某一次工具返回的原始内容完整看一遍。如果你自己读着都觉得“跟这个问题没关系的信息占了八成”，模型面对的也是同样的八成。

5. 每一趟往返都要留得下来

这一条是整节的底线。前面四条都在讲怎么让它不出错，这一条讲的是出错之后你能查清什么。

要能回答的问题很具体：这一轮模型看到了什么、决定了调哪个工具、填了什么参数、工具真的返回了什么、这个动作是谁触发的。少任何一项，事后复盘就只剩猜。

这件事在演示阶段完全看不出价值，它只在出事那天值钱。而且它有个副作用是正面的：把过程摊开之后，用户对智能体的信任度会明显不一样。看到一个数字和看到这个数字是怎么查出来的，是两种感受。

> 判断方法：不要看有没有日志这个功能，去挑上周三下午的一次真实调用，让运维的人回答：这次是谁发起的、走了哪几个工具、每个工具返回了什么。限时十分钟。答不出来，就是没有。

6. 分清是判断错了，还是执行错了

智能体出问题，团队最常见的反应是去改提示词。但问题可能根本不在模型那一层。

大概是三个层次：

• 判断错：该调 A 工具它调了 B，参数明显不合理。这是提示词和工具描述的问题。
• 执行错：模型填得没错，但工具超时、接口挂了、返回格式变了。这跟模型一点关系没有，改提示词也改不好。
• 理解错：工具返回的内容模型理解偏了，或者返回的东西被剪过头，关键信息没了。

这三个层次的处理方式完全不同。混在一起，就会出现“提示词改了七八版问题还在”的局面。

> 判断方法：下一次出问题的时候，先别动提示词。把那一轮的报文调出来，看模型填的参数本身对不对。如果参数是对的，那后面所有环节的问题，都不该用改提示词来解决。

7. 提示词和工具描述是资产，不是配置

最后一条容易被当成管理话术，其实它很实际。

系统提示词改一句话、工具描述改一个词，行为会变，而且变在哪儿不一定看得出来。这类改动如果没有版本记录，出了问题连回滚都回不去。企业里真正稳的做法是：提示词是存在平台里的模板，带参数、可试跑、有版本；工具说明由接口结构统一生成，而不是每个人手写一份塞进去。

这一段的价值不在于规范，在于当智能体行为发生变化时，你有办法回答“是从哪一次改动开始的”。

> 判断方法：问做这个智能体的同事一句：上个月改过几次系统提示词？如果答案是“记不清了”，那你们现在其实是在手工维护一个没有版本控制的生产系统。

七、这些考虑在模釜里落在哪些地方

上面七条讲的是要管住什么。这一段说在模釜（AgentSteamer）里，它们分别对应哪些已经做出来的能力。

关于每一趟往返看得见。 模釜的智能会话是任务执行的统一入口，模型的思考过程和工具调用过程以事件形式实时推给前端，可以折叠展开，不是黑箱。会话追踪能把一次调用走了哪些节点、中间调了哪些工具、每一步输出了什么逐层摊开看。这一条对应的就是第六节的第 5 条。至于会话里产生的文件，会被自动收进制品仓库，可预览、可下载、可追溯。

关于工具清单怎么来的。 平台兼容 MCP 协议与 Agent Skills 规范，工具说明不需要手写。接入一个 MCP 服务时，平台读取它声明的参数结构，动态构建成给模型看的那份说明书；工具清单的名称也会注入系统提示词的工具段，供模型感知。MCP 返回的内容会自动拆出正文文本再回灌，不会把一整包协议外壳塞进上下文。这一条对应第 7 条里“工具说明由接口结构统一生成”。

关于执行发生在哪里。 所有真实动作限定在隔离沙箱里完成，每个会话有独立目录，多轮之间复用同一份工作区，会话删除时目录一并清空。权限体系是 11 类资源 × 10 类操作的 RBAC，带部门级继承。模型建议调用什么，和执行层放不放行，在模釜里是两层。这一条对应第 1 条。

关于上下文预算。 短期记忆按 token 窗口截断，满了按策略丢弃，可以先丢最早的，也可以按重要性丢；token 消耗接近阈值时，系统会让模型把之前的对话归纳成一段摘要替换掉旧消息。这一条对应第 4 条里“工具返回的东西要剪过再回灌”的同一本账。记忆体系本身是后面单独一篇的话题，这里只说它和上下文预算的关系。

关于成本和节奏。 模型用量的数据在看板上按多个维度排名，应用详情页有调用次数、平均耗时、成功率、token 消耗四项统计。接口层有统一限流，内置了工作流执行、发送消息、知识检索等九条规则，redis 不可用时回退内存。这一条对应第五节那张账本和第六节的第 3 条。

关于出错的信号。 工作流执行完成和执行失败都会作为事件推给 Webhook，可以做签名校验、配重试次数和超时；审计日志记录操作人、资源、IP 和状态；通知中心承接这些事件。这一条对应第 6 条里“分清是判断错还是执行错”。

关于资产。 提示词在平台里是带参数的模板，可以一键试跑，版本自动递增；应用本身有完整的版本管理，可以一键回滚到任一历史版本。这一条对应第 7 条。

关于模型。 模釜不绑定特定大模型，通过 OpenAI 兼容协议接入任意端点，OpenAI、Azure、DeepSeek、Qwen、Ollama、vLLM 都在支持范围内，也可以换成企业在内网自建的推理服务。这篇文章讲的报文格式是所有走这套协议的大模型共有的，不挑厂商。知识库要用的向量模型和重排序模型是内置的（BAAI/bge-m3 与 BAAI/bge-reranker-v2-m3，MIT 协议可商用），不依赖外部接口。

模釜（AgentSteamer）由上海临境绘谷信息科技有限公司研发，支持完整私有化部署，知识库、制品、会话记录这些数据全部留在企业内部。

八、常见问题（FAQ）

智能体是怎么收到大模型的消息来执行任务的？

大模型并不主动“发消息”给智能体。整个过程是智能体主动发起的循环：它把系统提示词、工具清单、对话历史和本轮输入组装成一条请求递给模型；模型输出一段结构化文字，声明想调用哪个工具、填什么参数；智能体解析这段文字，校验参数与权限后真正执行，再把执行结果连同原来的全部材料重新组装成一条新请求递回去。这个往返重复到任务结束或触发上限为止。

一次工具调用要来回几趟？

最少三趟。第一趟把材料递给模型，第二趟模型返回工具调用声明，第三趟把执行结果连同前面全部内容再递给模型。如果模型看到结果后还要再查一次，就继续加趟。真实任务里转十圈以上很常见，这也是智能体耗时和花费的主要来源。

模型输出的工具调用内容长什么样？

是一段格式固定的结构化文字，通常用 JSON 表示，包含三部分：要调用的工具名称、要传的参数键值对、以及一个用于对号回执的调用编号。同一段输出里可以同时包含多个工具调用。对模型来说，写这段文字和写一句普通回答是同一个过程，都是预测下一个词。

为什么模型填的工具参数总是出错？

因为参数是模型“生成”出来的，不是从你的系统里“读”出来的。它优化的是“看起来像”，不是“是不是真的”。所以日期格式、编号大小写、单位符号、字段命名这些细节最容易出错。工程上的应对办法是把参数结构写清楚（字段类型、是否必填、格式示例），并在执行前做一遍结构校验和取值校验，而不是直接照单执行。

工具执行的结果为什么要剪短了再给模型？

因为每一轮请求都要把前面的全部内容重发一遍，工具返回的原始内容会一直留在上下文里，在后续每一轮重复计费，还会挤占模型能看到的其他材料。原始数据堆得太多时，模型对夹在中间的部分还容易忽略。所以真实系统里工具的返回内容通常是被设计过的，只保留相关的字段，长文本先截断，列表先聚合成一句概括。

企业智能体稳健运行最要紧的是哪一条？

如果只能选一条，是执行层的授权与校验，也就是别把模型填的表当成指令。模型负责提出意图，能不能执行、参数合不合法、发起人有没有权限、要不要走审批，这些必须在执行侧判定。其余几条（防重复执行、硬性上限、返回内容裁剪、全过程留痕、错误分层排查、提示词版本化）都是在这条成立之后才有意义。

智能体为什么会卡在某一步反复重试？

通常有三个原因叠在一起：工具返回的错误信息写得太像线索，模型据此不断换参数重试；没有设置硬性的轮数、时长或花费上限；以及这个错误本身属于执行层问题（接口超时、格式变化），改提示词也解决不了。工程上要同时设上限，并让执行层的错误干脆地暴露出来，而不是包装成一句模糊的失败提示。

换了更强的大模型，这些问题会自动变好吗？

不会。模型变强，只影响“它判断得对不对”这一层。而报文结构、参数校验、防重复、轮数上限、返回裁剪、留痕这几件事发生在模型外面，属于工程问题，不随模型换代自动解决。真实项目里卡住智能体能不能上线的，多数是后面这几件。

模釜（AgentSteamer）和这套机制是什么关系？

模釜是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，支持完整私有化部署，且不绑定特定大模型。本文讲的三条报文的往返结构，在模釜里由工作流执行引擎负责编排：工具清单从 MCP 服务声明的参数结构动态生成，执行动作限定在隔离沙箱内完成，每一步的工具调用过程以事件形式推给前端并可在会话追踪里逐层查看，提示词以带参数的模板形式管理。企业需要的基础设施部分，平台侧已经落地。

九、几个名词的通俗解释

• 系统提示词（System Prompt）：智能体每一轮都固定带给模型的那段说明，定身份、定规矩、定输出格式。它在每一轮都在场，所以措辞上的含糊会被放大很多遍。
• 工具清单（Tools）：递进请求里的一份可用工具目录，每项包含名称、描述和参数结构。模型只能从这份目录里选，目录里没有的它点不出来。
• 参数结构（JSON Schema）：描述工具参数的一种约定，标清楚每个参数的类型、是否必填、取值范围和格式示例。写得含糊，模型就只能猜。
• 工具调用（Tool Calls）：模型输出的一种结构化内容，声明想调用哪个工具、填什么参数，还带一个用于对号回执的调用编号。它是模型的输出，不是真正的执行。
• 回执（Tool Result）：工具执行完之后回灌给模型的那条消息，标记里要挂上对应的调用编号。同一轮里有多个调用时，靠这个编号区分谁对谁。
• 往返（Round-trip）：智能体递材料、模型返回、智能体再递回去的完整一轮。一次工具调用至少三轮，轮数是智能体成本与耗时的主要变量。
• 上下文窗口（Context Window）：模型一次能看到的 token 总量上限。每轮都要把全部内容重新放进来，所以它同时也是这笔生意的成本上限。
• 幂等（Idempotency）：同一个操作执行一次和执行多次的结果一致。模型超时重发、用户重复点击时，写操作类工具靠它避免把同一件事做两遍。
• 隔离沙箱（Sandbox）：一个和主系统分开的执行环境，智能体的命令执行和文件操作在里面进行，出事时影响范围可控。
• MCP（模型上下文协议，Model Context Protocol）：一套让外部工具用统一方式描述自己、并被智能体平台接入的开放协议。工具的参数结构可以据此自动生成给模型看的说明书，不必手写。
• Agent Skills：一套智能体技能的规范，技能以标准包的形式导入导出，可跨平台复用。
• 审计日志（Audit Log）：记录谁在什么时候对什么资源做了什么操作的日志。它回答的是“这件事是谁发起的”，而不是“模型说了什么”。

写在最后

回到那张截图。4 秒和 41 秒的差别，是两趟和十一趟的差别。

讲完之后那位客户问了一个我觉得挺关键的问题：那能不能让它别转那么多圈？

能，但办法不在模型上。那个例子里真正该改的是三件事：工具描述里把仓库名的可选值列清楚，模型就不会一个个试；工具返回的错误写得干脆一点，模型就不会一直换着法子重试；执行层设一个轮数上限，转不动就停下来交给人。

三件事都发生在模型外面。这也是我做这个方向这几年最实在的一个体会：智能体能不能上线，主要不取决于你选了哪一版模型，取决于那几趟往返里，有多少字段是你认真设计过的。

模型每升一版，第一件事自动变强。第二件事没有人替你自动做。

模釜（AgentSteamer）是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，我们做的很大一部分工作就是把这篇里的这些字段变成平台上可配置、可查看、可追溯的东西：工具清单从接口结构生成、执行关在沙箱里、每一步过程摊开给你看、提示词带版本存在平台里。

至于任务怎么拆、多个智能体之间怎么分工、记忆和知识库该怎么做，那是后面几篇的事。这篇把一趟往返说明白了，剩下的才好往上装。

关于我们：上海临境绘谷信息科技有限公司 | 企业级 AI 智能体平台 模釜（AgentSteamer）