外观
第 5 章 智能体是怎么工作的
模型再博学，出口也只有文字，让它出上周的经营周报初稿，它只会回一篇周报写作指南，一条数据也拿不出来。答案第 1 章讲过，装上工具和自主权，大模型就从会说话变成会办事，本章把这个答案拆开看。5.1 讲智能体回路与工具调用，5.2 讲推理四件，5.3 讲编排模式谱系，5.4 讲多智能体何时值得，5.5 讲记忆与个性化，5.6 把这一章的词收进三场研发会议，铺一张协作的词汇表。
案例线还是第 4 章立起的那家茶饮连锁，第一单已经选定，运营小周每周的归因周报。本章跟着这一单走，看“出一份周报”这句话，怎么变成一份真交得出来的周报。读完自查一句话，能向同事解释清楚智能体为什么有时聪明有时表现差，这一章就过关了。
5.1 智能体回路与工具调用
智能体的骨架是一个循环，智能体回路（Agent Loop），三样东西装进同一个循环里转，模型负责拿主意，工具负责动手，记忆负责存状态。接到目标、想一步、调工具、结果回喂、再想下一步，一圈一圈转下去直到交差。回路怎么转，拿小周的周报任务走一遍最清楚。假设产品已经搭起来，周一早上他在对话框里敲下一句：“出上周的经营周报初稿，三家店，重点说清销售为什么变动。”
如果对面坐的还是第 2 章那个模型，他只会收到一份《周报应该怎么写》。要让它干活，得按回路配齐三样，记忆这件先记一笔，这场对话里说过什么、查过什么、查到哪一步，都归它管，5.5 细说。回路的五步如下。
第一步，接到目标。小周那句话进来，连同产品事先配好的规矩（任务范围、指标口径），就是它眼下的全部已知。
第二步，想一步。模型把已知情况读一遍，判断当下最该干什么，写归因先得有数，先查三家店上周的销售明细。这里的“想”是借个说法，底下干活的还是第 1 章那个按概率接话的模型，它接的话变成了“下一步该干什么”。
第三步，调工具。它开口要工具，说的是“用查销售这支工具，条件是上周、三家店”。研发管这个动作叫函数调用（Function Calling），说的就是模型以标准格式发出一份“用哪个工具、带什么条件”的请求。真正执行的不是模型，产品这边的程序接过请求，去收银后台把数取回来。模型从头到尾不碰任何系统，这一点产品经理要记牢，它“会查数据”的真相，是它会开查数据的单子，单子执行得成还是执行不成，取决于产品给它配的工具好不好用。
第四步，结果回喂。取回的数递回它手里，变成下一步的输入。它看到 ST002 掉得最狠，下一步就奔着 ST002 的促销记录去。
第五步，再想下一步，直到交差。再想、再调、再看，一圈一圈转下去，查完销售对促销，促销解释不了再看损耗，信息凑齐，它写出周报初稿交回，回路停转。
图 5-1 画的就是这五步。顺的时候模型自己判断信息够了、主动收尾；不顺的时候还有两条出路，同一处查来查去打转，转数上限让它停下；工具连续失败，报告任务失败、转人工接手。后两种是回路的正常收场，算不上事故，用户在那两种时刻看到什么、谁来接手，是产品要设计的体验，第 10 章的兜底专门讲。
回路怎么配，一半是产品决策，集中在工具的三层上。第一层，接哪些工具。第 1 章讲过，工具是产品方接上去的，不是模型自带的。给周报帮手接上查销售、查损耗、查促销三支工具，它就是经营分析帮手；再接上发消息的工具，它就能把周报直接发进群里。工具清单画到哪，产品的能力边界就到哪，第 7 章写产品定义时，能力清单的原料就是这张工具表。
第二层，每个工具给多大权限。查销售是只读的，调错了顶多白查一次；发周报、改订货是写操作，错了要花真金白银补救。第 4 章粗算里那道防线，是周报发出前留小周核对，放到工具上，就是把“发”这支工具的执行权留在人手里，模型只能提请求，发不发由人定。
第三层，工具切多粗。把“查销售”和“改订货”合成一支大工具，模型一步到位，也失去了查完停下来的机会；拆成两支，中途判断权就还给模型。粒度切在哪，本质是把多少判断交给模型，与第 3 章讲的自主度，是同一件事在工具上的样子。每支工具还要配一份说明，名字、用途、要什么条件，写得越清楚，模型用得越准。查促销这支工具的说明里没写清日期口径，模型查回来的数就可能差着一周，归因从第一步就歪了。这份说明是写给模型看的产品文档，怎么写，第 7 章展开。
接工具这件事还有一个行业标准要知道，MCP（Model Context Protocol，模型上下文协议）。前面的工具都是产品方一支一支接的，每接一个系统，研发就要写一遍对接代码；市面上的智能体应用有 N 家，值得接的工具和数据源有 M 家，两两对接就是 N 乘 M 份工作。MCP 把接口的形状统一，工具源把能力做成标准服务，应用这边接一次协议，之后按这个标准做的工具都直接插得上，N 乘 M 变成 N 加 M。协议 2024 年 11 月开源发布，主流模型厂商先后采纳，已经成了行业通用件（口径见本章参考资料）。对产品经理它有三层含义。其一，工具生态决定能力供给，规划功能先查有没有现成的 MCP 工具，查数据库、接工单、读日历这类通用活大概率有人做过，不必列入自研。其二，把自家服务做成 MCP 工具开放，别家的智能体也能调到，等于多开一个分发入口，18.1 讲生态时回到这点。其三，协议省掉的是对接代码，省不掉信任，每支工具接进来，授权给多大、数据碰不碰，仍要一支一支审，第 14 章展开。
工具之外还有一类要求与它配套，结构化输出（structured output）。人读一段话就能懂，下游的程序要的是固定格式的数据，让模型按规定格式交结果，字段叫什么、什么类型、各填几个，都在要求里写死，产出才能直接进数据库、直接触发流程。前面第三步那张工具调用的单子本身就是一种结构化输出，模型按固定格式报出用哪支工具、带什么条件，程序才处理得了。产品含义体现在验收上，格式一固定，检查就从读起来对不对，变成字段和类型对不对，程序能自动核，按批验收才有基础，第 11 章规则层的裁判靠的就是它。
回路还给了排查问题一套现成的分诊框架。它答非所问，先看模型判断那一侧；工具明明调了没效果，去查执行那一侧；忘了上一句说过什么，翻记忆那一侧。先锁定组件再抠细节，这是与研发开 bad case 分诊会时的共同语言，11.6 会看到那场会怎么开。
再立一个成本直觉，回路每转一圈，都是一次完整的模型调用，而且圈数事先说不死，这周查三轮够了，下周可能查六轮。每一圈都按词元付费，圈数不定，单份周报的成本就天生带着波动。第 12 章的细算，以这个直觉为底。
最后补一个行业词，智能体外围骨架（agent harness）。模型本体之外，围着它转的那一整套外围件，回路、工具、权限、上下文管理、会话，合起来叫 harness，指的是给模型配上的全套干活装备。研发搭智能体多数不从零写起，用 LangChain 这类框架起步，5.6 的词汇表里列了几个。见一个成熟实例更容易建立体感，Anthropic 的 Claude Code 就是一套完整的编码智能体，终端里接活、列计划、读写文件、跑测试、过权限，它是本书讲的回路、工具、档位的一次完整落地，对照着看，很多设计决策都眼熟。这个词的价值在沟通，研发说换一套骨架、说骨架里自带会话管理，产品经理知道说的是外围件，不是模型本身。
5.2 智能体的推理原理
同一个帮手，上周的归因写得头头是道，这周把促销的影响记到天气头上，差别就在它怎么想这一步。模型本身还是按概率接话，但“想”这件事在智能体身上有了具体形状，一共四件，思维链、反思、规划分解、ReAct。2022 年，研究者给其中两件起了名字，这几年它们已经从纸面上的技巧，变成了各家旗舰模型出厂自带的能力。
头一件是思维链（Chain-of-Thought），把想法写出来再答。直接要答案，等于逼模型从题目一步跳到结论。第 1 章讲过它的工作方式，一个词一个词往外接，前面的内容是后面的依据。让它先把推断过程写出来，情况就变了，“先看品类、再看客流、再对促销日历”这些中间结论写在纸面上，后面的每一步都直接踩在写下来的前一步上，不用全靠它当场记着。拿周报来说，让它归因 ST002 为什么掉，直接要结论，它容易甩一句“受周边环境影响”交差；要求先写推断过程，结论就有据可查，就算错了，错在哪一步推断上一目了然，这对验收是实打实的好处，店长核对初稿时能顺着链条挑错。这两年新出的一批模型把分步思考练进了出厂能力，行业里叫推理模型，用户看不见的地方模型自己就会想。产品含义跟着来，多想一步不是免费的，思考写出来的每个字都按量计费，等待时间也跟着拉长。日常问答想一步就走，月度复盘才值得想透再答。这一档位分配，第 12 章算成本时还要回来。
第二件是反思（Reflection），干完回头检查。初稿写完，回头检查归因方向对不对、证据链断没断，这一步就是反思。它更值钱的场合是查证不顺的时候，查了两轮都没找到 ST002 的促销记录，会反思的帮手停下来想一句“可能方向错了，改查天气和客流”，不会反思的一直硬冲，把轮数耗光还空手而归。反思也有成本的讲究，顺顺当当的简单步骤不值得每步都停下来检查，白付一段延迟，检查要花在关键节点上，交稿前、换方向前。
第三件是规划分解（planning），大任务拆小步。接到“出周报”这种整任务，先列一张清单，取数、对指标、归因、成稿，再按单干活，干一件划一件。它与第 4 章阶梯里写死的流程自动化是两回事，单子是它自己现场列的，不是开发期写死的。任务“步骤说不清”的时候还能交出一张合理的单子，这正是 4.3 任务画像里那类活配得上智能体的原因。拆步也有坑，拆出来的子目标会打架，“结论要快”和“证据要全”顶到一起，它可能悄悄丢掉一个，谁也不告诉。解法不在模型侧，在任务交代里把优先级写明白，这是第 7 章需求定义的活。
第四件是 ReAct，边想边干。名字是英文两个词拼的，Reasoning 加 Acting，推理加行动。想一步、做一步、看一眼结果、再想下一步，这正是 5.1 那圈回路的节奏，四件里它的角色特殊，是把前三件串起来的干活节拍。周报里最典型，查完销售看一眼，掉得集中在 ST002，下一步就查它的促销；促销对不上，再想是不是天气；天气数据查不到，就在初稿里标注存疑，而不是编一个原因填上。下一步干什么，取决于上一步查到了什么，这种活，先把全盘计划定死再动手是干不了的，4.3 讲过这正是归因任务的特征。
四件合起来，就能回答本节开头的问题，智能体为什么有时聪明有时表现差。聪明的时候，想得细（思维链）、回头查（反思）、拆得清（规划）、走得活（ReAct），四件配合着转。表现差的时候，是中间某一环接歪了，推断的起点错了，检查那步跳过去了，清单列偏了，或者上一步的工具结果读错了。第 3 章讲过概率性行为是它的固有特性，同一个任务两次走的路可能不同，四件东西是把它往稳里带的手法，不是根治，验收照样要按比例定，这条底线不能松。
还有一条钱上的因果要连起来，它多想的每一步、多查的每一轮，都要花钱花时间。“为什么这次跑一份周报的钱，比上次贵了一倍”，答案多半就在这四件里，这次它想得多、查得勤。把“想多细”定成产品决策，不要任由模型发挥。
5.3 编排模式谱系的产品含义
一个产品里几个帮手、谁管谁，答案排成一条谱，叫编排模式谱系，从路径开发期写死，到路径完全交给模型，五种模式各占一段。编排说的是活怎么拆、拆给谁、按什么顺序交接，模式说的是这条拆法写在谁手里。
谱系最左端是工作流（workflow），路径开发期写死。4.6 已经把每天那三张报表的取数、汇总、排版判给了固定自动化，从编排的视角再看一眼，整条路径的先后顺序，工程师提前写好，模型只在个别需要语言判断的环节参与，比如数字异常时补一句说明。工作流的下一步全部写死，按第 3 章“谁决定下一步”的判据，它站在智能体的界外。这不是缺点，写死意味着便宜、可预期，错在哪一步也说得出来，该写死的写死，是第 4 章选项阶梯在编排上的用法。
往右一格是路由（router），干的是前台分诊。问题进来先判断是哪类，再派给对口的帮手，店长问“昨天损耗怎么这么高”，派给问答帮手；小周要周报，派给周报帮手。分诊这一步本身可以写死（按入口分），也可以交给模型（按问题内容分），两种做法的价钱和灵活度都不同。
再往右是并行（parallel），三路同时查。三家店上周的销量互不依赖，拆三路同时取，最后合成一份，比一家一家查快得多。并行的前提只有一条，拆开的子活之间真的互不依赖，不然合成的时候数字对不上。
谱系中段偏右是监督者（supervisor），组长派活。一个组长智能体接下整单任务，拆开派给几个专项帮手，取数的、归因的、成稿的，收齐拼总，不够再派。它与路由的差别在深度，路由分完就完，监督者全程管协调，是一个用模型当调度的结构。
最右端是单智能体，5.1 那个回路，一个帮手带全套工具，整条路自己走完。
排序的标尺还是本节开头那句，拆法写在谁手里。监督者现场定的是派谁、按什么顺序派，帮手的名单、分工和收齐拼总的框架，设计期就搭好了，组长只在框架里调度；单智能体连这层框架都不预设，走几步、每步用哪支工具，全在运行时定，所以一个排在中段偏右，一个独占最右端。
这张谱对产品经理有三层含义。第一层，模式决定成本。写死的部分搭好之后几乎不再花钱，交给模型的部分按调用计费，还带概率性。选模式等于在第 4 章的阶梯上按段落位，整件事用一种模式套到底，多半是没拆段。日报线走工作流，周报归因走单智能体，两条线各用各的，4.6 那个“值得做、分层做”的结论，工程上的样子就是这张谱。
第二层，产品形态跟着模式走。工作流是后台自动化，用户只看见结果；单智能体是委托，用户交代目标、收成果；监督者像一个团队，用户面对的往往还是一个入口。第 8 章的形态选型，骨架埋在这里。
第三层，出错面也随模式变。路径写死的，错在哪一步，指得出、改得动，日报哪天没发，看一眼定时任务就定位了。路径交给模型的，两次走的路可能不同，排查要翻它的执行记录，第 15 章的可观测性就是为这个准备的。模式越往右，能力越强，要盯的东西也越多。
拿小周产品线的三条线在谱上排一遍，位置就具体了。每天的日报，步骤固定、口径固定，排在最左端，走工作流，4.6 已经定过。店长随时来问数，问题五花八门但都围绕着三张报表，一个问答帮手带查询工具就够用，排在右端，走单智能体；将来问答和周报两条线都要从一个对话框进来，前面加一层路由，按问题内容分诊。真到三条线都跑满、一个入口忙不过来，才需要监督者结构，那是产品长起来以后的事，不是第一天的架构。
怎么选，一句话说清，能写死的写死，需要现场判断的交给模型，一个入口装不下多种活，就加一层路由或监督者。反过来拿着最时髦的模式套任务不可取，监督者、多智能体这些词在评审会上有面子，但模式要匹配任务本来的样子，这句话 4.3 结尾说过，这里原样适用。
5.4 多智能体何时值得
多智能体的代价不小，拆开之前先过三个问题，工具清单一样吗，材料一份装得下吗，多花的钱从哪省回来，多数提议经不起这三问。评审会上常有人这么提议：“周报产品搞三个智能体吧：分析师管归因，撰稿人管成稿，审查员管把关，各司其职。”话说出来很少有人反对，毕竟听着专业，把代价拆开看，才知道这一步有多贵。
头一笔，传话即成本。组长读一遍任务写派单，分析师读派单干活，撰稿人把分析结果整个读一遍才动笔，审查员再把前两人的产出合起来读一遍才发言。每个角色每次开口，都是一次完整的模型调用，而且角色之间传来传去的材料，都要重复计费。有公开评测做过一件干脆的事，同一款模型，分别装成直连、单智能体带工具、三人多智能体三种配置，跑同一批任务，三人组的消耗是直连的四十多倍（一次评测、一款模型的口径，量级可信，倍数别当常数，出处见本章参考资料）。
第二笔，传话丢话。上游帮手编错一个数，下游帮手拿它当真往下传，错误顺着交接链散播。多设一个审查员不等于多一道保险，审查员自己也是一次概率调用，可能放走坏结论，也可能误伤好结论。整条链的成功率是各环节连乘的，每环成功率 98%，十环串下来只剩约 82%。每多加一环，整体就脆一分。
第三笔，排错变难。单智能体的错在一份执行记录里，三个帮手的错散在三份记录里，还互相指认。延迟也跟着叠，帮手只能轮着开口，一轮一轮等。
那什么时候才值得拆？三个问题过一遍。一问，这活一个智能体带全套工具干得下来吗？几个帮手底层跑的是同一个模型，拆开并不会因此多出能力，多数业务任务一个帮手真干得下来。二问，真要拆，专长是真的吗？判据笨但可靠，把两个角色的工具清单摆出来比。清单不一样的才叫分工；工具一样、只差“资深分析师”“细心审查员”这类头衔的，是角色扮演，加出来的无非是成倍的调用。三问，中间环节要读的材料，是不是大到一份装不下？真有大材料要啃，比如通读一整个月的店长群聊记录，有一个便宜得多的中间档，把啃大材料的活单独切给一个帮手，干完只交回一份摘要，主帮手的案头始终干净。这个做法叫子智能体（sub-agent），是多智能体里最便宜的一档隔离，很多看着非拆不可的产品，走到这一步就收工了。
拿这三个问题照案例线过一遍，周报第一单不上多智能体，第 4 章的分层结论已经决定了。一问，一个智能体带查销售、查损耗、查促销三支工具，从头走到尾，干得下来。二问，归因和成稿用的是同一套工具，不算两种专长，“分析师”和“撰稿人”拆开是白付传话钱。三问，三家店一周的报表，一份上下文装得下，连子智能体都用不着。所以第一单的架构就一句话，一个智能体，三支工具，小周核对那道关口照留。
真值得拆的长什么样？三问都拦不下来的，才有资格谈拆，工具清单真的分家，查数的、读群聊记录的、算财务口径的，各摸各的系统；材料真的太大，一个月的店长群聊几十万字，主帮手的窗口装不下；拆开的每一段产出，下游真的用得上。真长这样的活也有，横跨销售、供应链、财务三个系统的季度经营复盘，每个系统的口径都是一门学问，材料各自成山。这样的任务，拆开是花小钱办大事；不该拆的硬拆，就是花大钱办小事。顺序上还有一条经验值得带上，先隔离，后编排，先试子智能体这种只切材料、不搞协作的轻拆法，确实不够了，再上组长派活的重架构。多数产品走到轻拆法那一步，需求就已经满足了。
反过来还有一类毛病也常见，不在拆得太碎，在一个帮手身上堆得太满。查数、归因、写稿、发通知、答店长问，全塞给一个智能体，工具清单拉出十几支，哪件都沾，哪件都不精，它每次决策都要在一长串工具里挑，挑错的概率跟着涨。这类毛病与“三人协作”是同一个病根，架构跟任务没对上，解法也同一条，回到三个问题，按工具清单重新归堆，该合的合，该拆的拆。
下次会上那句“搞三个智能体”的提议再出现，手上就有三句现成的接话，工具清单一样吗？材料一份装得下吗？多花的钱打算从哪省回来？三句问下来，多半还是回到一个智能体。
5.5 记忆与个性化
模型本身不会记住用户，它的学问在训练结束那天就定了型，产品里那种“越用越懂我”的体验，全部来自产品设计配的记忆，记不记得用户，属于产品决策，模型自己不带。案例线里有个现成的例子，产品用进第二周，小周发现一件别扭事，每场对话都得重新交代一遍“三家店的编号、环比口径、周报别超过两页”，帮手不记得他。
记忆分三档，各管一摊。短期记忆（short-term memory），管这场对话。今天这场里小周说过的口径、指定要看的店、已经查过的数，中途他改一句“损耗那栏先不算了”，帮手能记住，不用从头再来。它的寿命跟对话一样长，窗口一关，全部清空。短期记忆兜住的是“手头的活干到哪了”。
长期记忆（long-term memory），管跨周跨月。老陈的店况，ST001 开在写字楼商圈，客流跟着工作日走；小周的偏好，环比优先，两页为限。这些存下来，下周一新开一场，开口就能续上，不用他把背景重讲一遍。它兜住的是“这个人、这家店是什么样”。
情景记忆（episodic memory），是长期记忆里管旧事的一支，上次类似的事怎么结的。上上周“降温带动热饮”那条归因，老陈点头证实过，这次再来一段类似的销量波动，帮手先翻旧例作参考。旧例帮得上忙，也可能带偏，这是它单拎出来讲的原因，旧案例是资产，也是包袱。旧归因攒得多了，还能反过来当评测的测试题，拿上个月它自己下的结论，问它现在还成不成立，第 11 章的评测计划里见。
三档记忆带来的好处是实打实的，个性化有了着落，交代成本一次付清，归因有历史可依。第 3 章讲持续进化是智能体的成长通道，进化要的反馈，一半就存在这里。
真正难的是产品决策那一半，记什么，忘什么，往哪边偏都有代价。什么都不记，产品永远是第一天上班的实习生，每个用户每天都得重新教。什么都记，灾难换了个方向，过期信息污染判断。三个月前老陈还在试销的旧菜单赖在记忆里，这次归因就会把销量变动算到早已下架的品上；寒暄和废话挤占地方，真要用的翻不出来；更有一条硬底线，身份证号、手机号这类信息根本不该进记忆，拦住它的是产品这边的校验，不能指望模型的自觉，第 14 章正面讲这条线。
所以记什么忘什么，得产品拍板，写成规则。什么时候写，任务结算时抽取偏好，归因坐实后记下经过。写什么格式，店况一条、口径一条，不要整段聊天记录往里灌。活多久，衰减快的（上月的活动规则）定期清，衰减慢的（店况、偏好）长期养。这些记忆放在哪，产品上也有轻重两档，小周的偏好拢共十几条，一份小档案就装下，每个会话开工读一遍；旧归因的案例库天天在涨，攒到几百条，才值得配一套按内容检索的存法。起步先用最简单的存法，不要一上来就搭重型设施。
忘也是功能，不只是省地方。再往下一步，让用户看得见产品记了什么、能一条条删掉，既是合规动作，也是信任动作，第 9 章讲透明度时接上。记忆做得好不好，验收时专门有一套测法，新开一场对话，测试它上一场该记的事，答得上来才算真的存了下来；更进一层是测“不问也用得上”，小周说过一次“别超过两页”，下一份初稿直接就是两页，不用再说第二遍。测法细节第 11 章展开。
把这一节与前面两章的内容合起来，还有一门统管的学问要点名，上下文工程（context engineering）。上下文窗口是模型一次干活看得见的全部，往窗口里放什么、不放什么、以什么形式放，由三件工具共同回答，2.2 的提示词是当场写给模型看的部分，2.3 的检索是按需取回资料的部分，本节的记忆是跨场保留的部分。产品经理不必会工程细节，但要守住一个判断，窗口是预算，进窗口的每个词元都占预算，给多了成本涨，给少了依据缺，什么信息放在哪个位置，是产品定义的一部分。
5.6 与研发协作的词汇
本章从头到尾攒了不少词，真实的使用场景不在背词，在开会。研发的会有三场最常开，需求评审会、性能核对会、方案讨论会，每场会上各有一批高频词，按会分组记，词才和场景连在一起。下面三张表共三十三个词，每个词配两句话，研发说它时在说什么，能接住的那一句。本章教过的词也收进来对号，整章的词一次归档。
第一场，需求评审会。这场会上研发说的词，多半在回答“这个需求怎么接进来”。听懂它们，谈“这个功能放在架构哪一层”时才插得上话。
| 词 | 研发说它时在说什么 | 你能接的那句话 |
|---|---|---|
| 函数调用 | 让模型以标准格式开口要工具，程序照单执行（5.1 的“开单子”） | 那这个需求里模型只开单、不执行，执行侧的校验谁来定？ |
| 工具定义 | 给每支工具配的名字、用途说明和条件格式，写给模型看 | 工具说明谁来写？这份“给模型看的文档”要进评审 |
| MCP | 模型上下文协议（Model Context Protocol），把工具和数据接进智能体的开放标准，各家工具做成统一插口，接一次到处用 | 咱们自建的工具要不要做成 MCP 插口？能白捡哪些现成的？ |
| 结构化输出 | 让模型按规定格式交数据，程序才处理得了，工具调用那张单子就是它的一种 | 这个需求里模型的产出要进系统吗？要进就先说好格式 |
| 系统提示 | 每次请求都带在开头、给模型定身份和规矩的那段话，用户看不见，却管着产品行为的一半 | 系统提示里哪些规矩是产品定的？改它算不算改需求？ |
| 提示词版本 | 写给模型的指令像代码一样编号管理，改一个字行为就变，要留版本、能回滚 | 这版提示词改了什么、过了评测没有，版本记录同步我一份 |
| 记忆 | 5.5 的三档：短期管这场对话，长期管店况偏好，情景管旧案例 | 这个需求要它记得用户的什么？记多久、谁有权删，先写进文档 |
| 上下文窗口 | 模型一次能读的内容上限，装不下的它看不见（第 2 章讲过） | 咱们最长的会话会撑到窗口多少？撑满了走哪条降级路？ |
| 温度 | 调模型接话随机程度的档位设置：调低更稳定，调高更多样 | 取数核对这类活温度压到低档了吗？创意场合再放开 |
第二场，性能核对会。这场会盯的是速度和账单，词都带着数字，产品经理要能听懂哪个数字对应哪段用户体验。
| 词 | 研发说它时在说什么 | 你能接的那句话 |
|---|---|---|
| token | 模型读写的计量单位，也是账单的单位，输入输出都按它计数 | 单份周报平均花多少 token？环比上月涨跌的原因查了吗 |
| 首 token 延迟 | 从发出请求到第一个字回来的时间，用户觉得“快不快”主要看它 | 问答和周报一个标准不合适吧，分开定目标 |
| 流式输出 | 答案一个字一个字往外送，不等整段生成完（第 1 章见过的“逐字往外蹦”） | 哪些场景开流式？周报这种长文不用等，问答一定要 |
| 并发 | 同一时刻有多少请求在跑 | 试点三家店没事，铺到一百家店的峰值并发算过吗？ |
| 限流 | 服务商对单位时间请求数设的上限，超了直接拒 | 大促那天的峰值在限流值以内吗？撞上限流时用户看到什么？ |
| 前缀缓存 | 每轮都要重发整段历史，开头不变的部分命中缓存按折扣计费 | 咱们会话的开头固定吗？能吃多少缓存折扣？ |
| 降级 | 主模型出问题时切备用模型或简化流程，保可用性 | 降级之后用户看到的是什么体验？降级路径谁来定义？ |
第三场，方案讨论会。这场会上争的是技术路线，词最多，也最容易把产品经理争成旁听。这张表里的前七个词本章都讲过，对号就能用；后十个是方案讨论会上点得出名字的路线和工具。
| 词 | 研发说它时在说什么 | 你能接的那句话 |
|---|---|---|
| 思维链 | 让模型把推断过程写出来再下结论（5.2 第一件） | 归因结论要不要强制附推断链？店长核对时用得上 |
| ReAct | 想一步做一步、看结果定下一步的干活节奏（5.2 第四件） | 咱们的回路就是它吧？执行轨迹留全了吗，出了错能回放吗 |
| 工作流 | 路径开发期写死的编排，便宜可预期（5.3 谱系左端） | 这段流程真的不会变吗？不会变就写死，别浪费模型的钱 |
| 监督者 | 一个组长智能体派活给专项帮手、收齐拼总（5.3） | 先过 5.4 那三问，专长是真的再上组长 |
| 路由 | 前台分诊，把问题派给对口的帮手（5.3） | 分诊写死还是交给模型判？两种价钱差多少？ |
| 子智能体 | 把啃大材料的活切出去、只交回摘要的隔离档（5.4） | 通读群聊记录这类活，切给子智能体就够了吧 |
| 多智能体 | 一群帮手互相协作完成任务（5.4 的拆分代价） | 工具清单一样吗？材料一份装得下吗？钱从哪省回来？ |
| 微调 | 拿自家数据继续训练模型，比改提示词重、比换模型轻的中间档 | 微调的收益评测集测得出来吗？值这笔投入吗？ |
| RAG | 先查资料再回答，知识放在库里不在模型里（第 2 章讲过） | 这个需求的知识从哪来？库里没有的它答不答？ |
| 评测集 | 一批真实任务加标准答案，产品改一次测一次，第 11 章的主角 | 这版改动过评测了吗？多少分，跟上一版比呢？ |
| 回归 | 改完把老任务重新测试一遍，确认没把原来对的改坏 | 回归跑的是哪套题？上批 bad case 加进去了吗？ |
| LangChain | 搭智能体应用的流行开源框架，把回路、工具接入这些通用活封装成现成零件 | 用它快是快，正式版的可控性和性能怎么把关？ |
| LangGraph | LangChain 一家的编排工具，把帮手和步骤画成一张图来管，主打流程可控 | 咱们的路由加监督者那层，用它搭原型多久能跑通？ |
| LlamaIndex | 主打接数据的一套框架，检索增强那条线的常用件 | 咱们 RAG 那层用它搭，换检索方案的成本高吗？ |
| Dify | 开源的低代码搭建平台，拖拽拼智能体和工作流，第 3 章品类划分里的搭建平台一类 | 内部工具先拿 Dify 搭个原型验证，够用就不自研 |
| 扣子 | 字节的智能体搭建平台，同样拖拽拼装，业务同学不写代码就能上手 | 业务侧自己搭的和咱们的正式产品，边界画在哪？ |
| CrewAI | 主打多智能体协作的框架，定义一队角色分工干活 | 上它之前，5.4 那三个问题我们先过一遍行吗 |
这张词汇表怎么用？开会前扫一眼当场所属那张，会上听到的生词当场记下、回来对表；对不上的，就是给研发同事的一个现成问题，问懂一个词，比会后自己猜半天划算。词汇是底子，日常的协作动作，bad case 分诊会怎么开、提示词跟研发怎么共管、验收测试参与什么，11.6 一场一场过。
本章小结
- 5.1 智能体回路。模型拿主意、工具动手、记忆存状态，接到目标、想一步、调工具、结果回喂、再想下一步，转圈直到交差；工具决策有三层，接哪些（能力边界）、权限多大（防线设在哪）、切多粗（判断权交给模型多少）；回路每圈是一次调用，圈数不定，单份成本天生波动。
- 5.2 推理四件。思维链把推断写出来，反思干完回头查，规划把大任务拆成单，ReAct 边想边干把前三件串起来；有时聪明有时差，差在某一环接歪；多想一步多花一步的钱，想多细是产品决策。
- 5.3 编排谱系。工作流、路由、并行、监督者、单智能体五种模式，从路径写死排到路径交给模型；模式决定成本、形态跟模式走、出错面随模式变；能写死的写死，现场判断的交给模型。
- 5.4 多智能体。传话即成本（三人组消耗直连四十多倍）、传话丢话、环节连乘（98% 十环约 82%）、排错变难；三个问题问下来多数产品不该从多智能体起步，周报第一单是一个智能体、三支工具、一道人工关口；真要拆，先隔离后编排。
- 5.5 记忆三档。短期管这场对话，长期管这个人和这家店，情景管旧事；记什么忘什么是产品决策，隐私信息不进记忆是硬底线，忘也是功能。
- 5.6 词汇表。三十三个词按三场会归档，需求评审、性能核对、方案讨论，从这一章起，研发会上没有旁听席。
案例线也在这一章定下第一单的架构，周报归因，单智能体回路，查销售、查损耗、查促销三支工具，推断链随结论交出，小周核对那道关口照留，日报线走固定工作流打底。判断力（第 4 章）和原理（第 4、5 章）到这里都齐了，下一章把视角拉高到全程，一个智能体产品从需求到上线要走哪几站，每一站产品经理交出什么。
试一试
- 把 5.1 的回路讲给同事听，挑一个你用过的智能体产品（第 1 章用过的那个就行），派它一个至少三步的任务，边看边还原：它接到的目标是什么、每一步想干什么、调了什么工具、哪一步的结果改变了它的下一步、最后怎么收的场。还原不出来的时候，正好翻第 15 章会讲的执行记录。
- 费曼检验，不看这一章，向同事解释“智能体为什么有时聪明有时表现差”，讲满四件推理手法加一个成本因果（多想一步多花一步的钱）。对方能复述，这一章过关。
- 拿 5.4 的三个问题照一个真实提议，找一份自家或听说的“多智能体”方案，把工具清单一样吗、材料一份装得下吗、钱从哪省回来这三个问题各写一句答案，再下判断。
- 记忆清单，给自己负责（或设想）的产品列一张“记什么忘什么”的清单，分三档各写两条，再单独列一条“绝不进记忆”的名单。
- 开会对号，带着 5.6 的三张表去参加一次研发会，记下会上出现的表内词，数一数哪张表出现得最多；再记三个表外的生词，回来问懂。
参考资料
- 《Building AI-Powered Products》（Marily Nika，O'Reilly 2025）第 8 章 Building AI Agents（智能体与聊天机器人之分、智能体的构成组件、主动式与响应式两类激活方式、定制与个性化检查单），见 txt/building-ai-powered-products.txt（英文原文，第 8 章行 6792 起）
- 《悟道智能体开发》（本书工程姊妹卷）第 2 章 智能体回路（模型-工具-记忆三组件、回路与三种退出、工具粒度即判断权的取舍：本章 5.1 的知识底本），工程深挖按该书对应章指引
- 《悟道智能体开发》第 3 章 结构化输出与推理骨架（思维链、反思、规划分解、ReAct 四件推理骨架，思考文字按输出计费的成本口径，子目标冲突：本章 5.2 的知识底本）
- 《悟道智能体开发》第 9 章 何时需要多智能体（四级阶梯、三问决策、多智能体的 token/延迟/调试/误差面四笔账、隔离与子智能体：本章 5.4 的知识底本）
- 《悟道智能体开发》第 8 章 记忆系统（短期/长期/情景分类、写什么忘什么由应用规则拍板、隐私信息不进记忆的硬线：本章 5.5 的知识底本）
- 《Designing Multi-Agent Systems》（Victor Dibia，O'Reilly 2025）第 10 章（四配置对比评测：直连、单智能体带工具、多智能体轮转、多智能体 AI 编排；三人多智能体编排每任务消耗 15,343 token 对直连 355、约四十三倍：正文“四十多倍”的出处与口径），见 txt-ref-zh/designing-multi-agent-systems/10-9 But What About Multi-Agent Frameworks .md
- 《AI Agents: The Definitive Guide》（Nicole Königstein，O'Reilly 中译）第 5 章（串行链可靠率连乘：单环节成功率 98%，十环约 82%），见 txt-ref-zh/ai-agents-definitive-guide/
- Anthropic《Building Effective Agents》（工作流与智能体的定义：前者为模型与工具沿预定义代码路径编排，后者为模型运行时自行决定流程与工具使用：5.3 谱系两端的机制出处），https://www.anthropic.com/research/building-effective-agents （核实于 2026-09）
- Wei J. 等《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》（思维链的提出，arXiv:2201.11903）https://arxiv.org/abs/2201.11903 、Yao S. 等《ReAct: Synergizing Reasoning and Acting in Language Models》（ReAct 的提出，arXiv:2210.03629）https://arxiv.org/abs/2210.03629 ，均核实于 2026-09
- MCP 官方站（Model Context Protocol：连接 AI 应用与外部系统的开放标准，生态支持与接入方式）https://modelcontextprotocol.io （核实于 2026-09）
- 《悟道智能体开发》（本书工程姊妹卷）第 5 章 MCP 协议（点对点集成 N 乘 M 到 N 加 M 的换算、2024 年 11 月开源与厂商采纳时间线、工具发现与授权），本章 5.1 的 MCP 段知识底本，产品向转述，工程深挖按该书对应章指引
- 框架与平台官方站：LangChain https://www.langchain.com （含 LangGraph 编排工具）、LlamaIndex https://developers.llamaindex.ai 、Dify https://dify.ai 、扣子 https://www.coze.cn 、CrewAI https://www.crewai.com ，均核实于 2026-09，能力口径以各官方文档为准