零基础开发AI Agent：十一个案例都跑通了，没一个能直接搬进公司

2026-11-14silcano

微信读书《零基础开发AI Agent——手把手教你用扣子做智能体》（管错、张心雨著）· 本篇读实战篇：第 7 至 11 章（专业分析、角色扮演、知识问答、内容营销、效率办公五类共 11 个案例），对应 p0257–p0472，共 216 屏。
抽样说明：抽读 p0268（三种编排模式）、p0272（温度与 Top P）、p0324（调研诊断报告节选）、p0356–p0358（多 Agent 的技能拆解与角色设定）、p0386–p0390（知识库三种格式与表格预处理）、p0442 与 p0455（模型参数面板）、p0462（代码节点统计字数），另核对 p0431（第 10 章全章）共 10 张。
这是全书最后一部分，也是我读这本书的第三篇：上篇是第 1–4 章与插件入门，中篇是第 5–6 章的功能模块，本篇只写实战案例，不重复前两篇。所有引文与界面数值均来自上述截图；凡属判断与批评，文中注明是我的看法。

先说结论：这 216 屏，是整本书最有价值也最不实用的部分。

有价值，是因为它终于给你看了十一个完整的成品：投标助手怎么读招标文件、调研诊断怎么出报告、意大利旅行怎么拆成两个 Agent 分工、企业知识官怎么用两个表格库做双索引。这些不是玩具，是把一个真实业务从"一句话需求"推到"能对话"的全过程，里面的提示词结构、参数取值、开场白写法，都能直接抄。

不实用，也是因为这十一个。它们全是单点、单人、单次的演示：一个人对着 Agent 说话，一次就成功，没有任何一条讲到多人协作、权限边界、并发、成本、上线后的维护。而这些恰恰是企业真正花钱的地方。所以这本书的实战篇，本质是十一场演示，不是十一次交付。

一、三个旋钮：编排模式、温度、Top P

如果只从这 216 屏里带走两页，我带走 p0268 和 p0272。

p0268 讲编排模式，三种：单 Agent（LLM 模式）——"智能体中只有一个 Agent，用户与大模型进行对话，适用于逻辑较为简单的智能体"；单 Agent（工作流模式）——"智能体中只有一个 Agent，用户与工作流进行对话"，书里的截图给它挂了个 Beta 标；多 Agents——"在一个智能体中设置多个 Agent，以处理复杂的逻辑"。

这三行字，其实是整个 Agent 世界的分水岭。第一类是"会聊天"，第二类是"会按流程办事"，第三类是"会分工"。绝大多数人做 Agent 失败，是因为用第一类的手段去解第三类的问题：把所有逻辑塞进一段系统提示词，指望模型自己分步骤。它偶尔能跑通，但你没法调试、没法复现、没法定价。

书里把这三类摆得很清楚，可惜没给一条判据。我的判据是这样的：能一句话说清输入输出，用第一类；有明显先后依赖、中间要调外部系统，用第二类；一件事需要两种以上截然不同的专业知识且互相不信任对方的输出，才用第三类。为什么是"互相不信任"？因为多 Agent 的唯一价值就是互相校验；如果两个 Agent 的判断完全一致，那把它们的活合并成一个更省钱。

p0272 讲参数，这一页写得比很多所谓的"进阶书"都干净。三种预设：精确模式生成随机性默认 0.1，平衡模式 0.5，创意模式 0.7。然后是自定义的两个高级参数：

生成随机性（temperature）：也叫温度。调高（最高为 1）会使输出内容更具有多样性和创新性，反之，降低（最小为 0）会使输出内容更遵循指令要求但多样性下降。
Top P（累计概率）：指大模型在生成输出内容时会从出现概率最高的词汇开始选择，直到这些词汇出现的总概率累计达到 Top P 值。

下面还有一句"小贴士"："生成随机性和 Top P 这两个参数一般只调整一个，建议调整生成随机性。"

这一句是全书我唯一想给它画重点的建议。因为实测里最常见的错，就是两个一起调：温度调到 0.9 觉得太飘，转头把 Top P 压到 0.3，结果输出既不通顺又不可控，还查不出原因——两个旋钮在互相打架，你永远不知道是谁的锅。只调一个，你至少知道因果关系。

投标助手这个案例正好用上了这套参数：因为要读招标文件、给出"比较严谨的输出内容"，所以选"精确模式"。这个选择是对的。招投标场景里，温度高一分，模型就可能给你编一个不存在的资质名称，而那个错会一路进到标书里。

再看 p0442 和 p0455 的面板，参数就具体了：Doubao-pro-32k/240615，32K 上下文；生成随机性 0.5、Top P 0.7、重复语句惩罚 0、携带上下文轮数 10、最大回复长度 4096、输出格式"文本"。另一个案例里是随机性 0.50、Top P 1.00、重复语句与重复主题惩罚各 0、最大回复长度 8192。

两组数放在一起看很有意思：一个是 4096 上限、10 轮上下文；一个是 8192 上限。为什么差一倍？因为前者是对话型 Agent，回答短、轮次多，4096 够；后者要出长文档（纠错、纪要），必须给到 8192。这个取舍书里没解释，但截图本身解释了。

而"携带上下文轮数 10"这个默认值，是全部参数里最贵的一个。它意味着每一轮请求都要把前 10 轮重发一遍。对话越长、上下文越贵，成本是超线性涨的。书里一次没算过这笔账。我在中篇已经说过一次，这里再说一次：不谈账单的 Agent 教程，是不完整的。

二、开场白与人设：那个主动说"我不是终稿"的 Agent

p0300 是调研诊断 Agent 的配置页，这一页藏着一个我很欣赏的细节。

作者在"设置记忆"这一步写得很干脆："调研诊断 Agent 不需要用户输入个性化信息，也不需要保存用户的特征信息，因此用不到变量和数据库功能，无须设置。"——注意这个思路：先问"这个 Agent 需不需要记忆"，答案是不需要，于是直接跳过。而不是"平台有这个功能，那我就配上"。这是全书少见的克制，值得单独表扬。

然后是开场白。作者说"可以不用设计开场白的引导问题，因为用户只需要上传文档，不需要输入指令"，接着给了这段：

Hi，我是一名 AI 咨询顾问，可以成为你的数字助理咨询顾问。
1. 我熟悉企业战略、组织、管控、制度、流程、人力资源、企业文化等专业知识和诊断分析思维框架，能够根据你上传的调研素材，快速、高质量地生成专业的企业管理调研诊断报告。
2. 需要说明的是，我的调研诊断报告可能并不是终稿，你需要在我输出的报告的基础上进行审核和完善，形成最终报告。

第二句是我在这本书里看到的最成熟的一句话。

它做的事，叫"预期管理"。一个会写报告的 Agent，最大的风险不是写得差，是写得太像样——用户看一眼觉得专业，直接转发给老板，结果里面某个数字是模型推的。开场白里先把"这不是终稿"说清楚，等于在第一次接触时就完成了责任划分。

这句话可以迁移到几乎所有生成型 Agent 上：合同审阅、财报分析、代码生成、医疗建议。用户要的不是"我什么都能干"，是"我知道自己哪儿不靠谱"。一个不肯示弱的 Agent，最后会被一次翻车全盘否定。

顺着这个思路，我甚至认为这句话应该做成平台级的模板，而不是靠作者自觉。凡输出长文档的 Agent，开场白强制带一句免责与人工复核提示——这比任何护栏提示词都有效。

三、两个专业分析案例：投标助手与调研诊断

第 7 章给了两个案例，都是"专业分析类"。投标助手干的事是把招标文件读成结构化字段：哪些是硬性资质、哪些是评分项、哪些是废标条款。调研诊断干的事是把一堆访谈记录和制度文件读成一份管理诊断报告。

这两个活有一个共同点：输入是非结构化的长文档，输出是结构化的判断。这正是大模型最擅长、也最容易出错的场景。擅长是因为它读得比人快；容易错是因为它会"补全"——文件里没写的条件，它会按行业惯例替你写上，然后你在评审现场被问住。

p0324 给了调研报告的节选，能看出这套提示词工程的成色。报告结构是这样的：调研基本情况（调研于×月×日至×月×日进行，共计×天；访谈管理人员×人，其中中后台管理人员×人、前台管理人员×人、中基层业务人员×人；收集战略相关资料×份、组织与岗位设置资料×份、绩效与激励相关资料×份、流程制度相关资料×份）；访谈主题（战略与经营：公司战略目标、战略落地、业务线发展、市场竞争；组织建设：组织架构、部门职责、人员配置、协同机制）。

书里对这份报告的评价是："这份报告出自调研诊断 Agent 之手，基本上可以达到高级顾问的写作水平。"

这句评价我要打个折。它达到的是"高级顾问的格式水平"，不是"高级顾问的判断水平"。你仔细看那份节选：它做的是把访谈素材归位、把数量填进模板、把主题分类摆整齐。这些都是格式活，做得确实漂亮，一个初级顾问要熬两个通宵。但高级顾问真正值钱的地方是——看完这些素材之后，敢说"你们的问题不在组织架构，在于老板越级指挥"。这句话不在任何模板里，也不可能靠填格子填出来。

所以我给这两个案例的定位是：它们能替掉一个分析师的体力活，替不掉一个合伙人的判断。而书里没有做这个区分，读者容易误以为"报告像样"就等于"结论可信"。这个误会，会让很多人在第一次真用的时候吃亏。

当然，作者也不是没意识到。前面那句"不是终稿、需要审核"就是补丁。但这个补丁打在开场白里，没打在案例的结论里，说服力弱了一档。

再说得具体一点，这两个案例的验收标准都缺失。投标助手的产出是"关键信息抽取"，调研诊断的产出是"一份报告"。前者其实可以用准确率衡量——抽十条，对几条；但书里没给任何评测集，也没说抽错了会怎样。后者更难衡量，只能靠人读。而"没有验收标准"的 Agent，上线就等于赌运气，因为你连"这次比上次好"都判断不了。

我在中篇说过"只给干净样本"的问题，这里要补一句更狠的：这两个案例连"干净样本"之外的输入形态都没交代。招标文件有扫描件、有加密 PDF、有夹杂附件的压缩包；调研素材有录音转写、有手写笔记、有微信截图。这些形态进来，前面那套漂亮的提示词要重写一半。书里所有输入都是规整文档。

四、意大利旅行：多 Agent 第一次露出真面目

第 8 章末尾的意大利旅行 Agent，是全书唯一一个真正的多 Agent 案例，也是我读得最仔细的一段。

它的拆法很实在：把旅行助手拆成"记账"和"财务分析"两个 Agent。记账这边要能干三件事——对用户的花销进行科目归类、汇率转换、明细说明；分析那边要能干两件事——按费用科目做占比分析、按每日总费用做横向对比。

注意这个拆法的逻辑：它不是按"功能模块"拆，是按"两种不同的思维方式"拆。记账是录入与归类，要的是准确和一致；分析是统计与比较，要的是视角和洞察。这两种活混在一个 Agent 里，提示词会互相污染：你让模型既严格记账又灵活分析，它两件事都做不好。

p0358 给了记账 Agent 的角色设定开头："你是一个专业的记账小助手，能够准确地拆解用户提供的话费信息，并以欧元为单位将其妥善记录到 payment_journal 数据库中。"

一句话里有三个约束：拆解（不是整段存）、欧元（统一币种，说明它要处理汇率）、payment_journal 表（落库，不是只在对话里说）。这是很标准的写法：角色 + 动作 + 单位 + 落点。比那些"你是一个专业的、经验丰富的、有十年从业经历的顶级助手"式的空话有用得多。

p0356 则展示了多 Agent 提示词的组织方式：用 ###技能1、###技能2 分块，每块下面写"什么时候用"和"回复示例"，示例用 ===== 包起来，里面是"汉语原文：<游客的汉语问题>""意大利语译文：<翻译后的意大利语>"这样的占位模板。技能 2 是反向的：把被询问人员的意大利语反馈录下来，翻成汉语。

这个写法值得抄。它的高明之处不在格式，在用占位符把输出结构锁死。模型最容易犯的错是自由发挥——你让它翻译，它给你翻译加解释加道歉。你把输出模板写成"固定标签 + 尖括号占位"，它就不敢多写。这是提示词工程里最便宜也最有效的技巧，书里没总结成方法论，但例子给对了。

不过这一段也有明显的粗糙处：技能 1 是游客问、你翻成意大利语；技能 2 是对方答、你翻成汉语。这两件事本质是同一个翻译动作的两个方向，为什么要拆成两个技能而不是一个"双向翻译"？书里没说。我猜是因为输出格式不同（一个要"原文+译文"，一个要"译文+原文"），但这属于我的推测。

多 Agent 真正的难点从来不是"能不能拆"，而是"拆完之后谁兜底"。记账 Agent 把一笔 80 欧的晚餐记成了 80 元，分析 Agent 拿到的就是错的基准，它不会质疑，只会算出更离谱的占比。这条错误链，书里一个字没提。

五、首席知识官：全书最好的一个工程做法

第 9 章的公司首席知识官，是这本书里我唯一想拍手的地方。

p0386 显示它建了三个知识库：一个文本格式的《CZ 集团总部制度汇编》，两个表格格式的——《CZ 集团制度清单-按类别》和《CZ 集团制度清单-按部门归口》。书里明确写了：

这两个表格格式的知识库的内容相同，一个以制度类别为主索引，另一个以部门归口为主索引，后续会介绍为什么要创建两个表格格式的知识库。

这叫同一份数据、两套索引。为什么这么做？因为用户提问的方式不同。有人问"差旅报销制度在哪"，他脑子里是类别；有人问"我们部门有哪些制度要遵守"，他脑子里是部门。你只建一套索引，另一半问题就会检索失败——而失败的样子不是报错，是"答得不太对"，用户根本不知道是检索错了。

这是全书唯一一处真正体现"数据建模思维"的设计。它不是平台功能，是使用者的判断。而这种判断，恰恰是低代码平台最不容易教出来的东西。

p0390 接着讲表格知识库的预处理，这一段含金量也高：

"表格由行和列构成，呈现的是结构化的信息，如果表格配置不当，大模型就难以准确地读取和匹配单元格之间信息的关联关系。"然后给了具体规矩：第一，表格的标题行最好为单行，不做合并单元格处理，以便系统准确识别表结构；如果出现多行标题、合并单元格等情况，就会识别不准确。

这条规矩看着琐碎，实际是无数人踩过的坑。企业里的制度清单、人员台账、物料表，十个里有八个是合并单元格的——为了好看。而合并单元格对解析器来说就是灾难：它不知道这一格覆盖了几列，也不知道下面的数据该归到哪个表头。你在 Excel 里看着漂亮的表，喂给知识库就是一堆错位的字段。

所以"AI 落地"这件事，很多时候第一步不是调模型，是让业务部门把 Excel 的表头改成单行。这句话书里没写，但它讲的那条规矩，指向的正是这个结论。可惜作者只写到"否则识别不准确"，没写"所以你上线前要先做一轮表格清洗"，读者很可能在项目中途才发现这件事。

六、效率办公：一个代码节点暴露的取舍

第 11 章有两个案例：文本纠错助手和会议纪要助手。前者里有一个细节值得单独说。

p0462 是一段跑在"代码节点"里的 JavaScript：函数 main 接收 params，把 input1 到 input7 七个字符串拼起来，然后用正则 /[\u4e00-\u9fa5]/g 匹配出所有中文字符，最后返回 { output: totalChineseCharacters }。

这段代码干的事，是数中文字数。

为什么这件事要写代码？因为大模型数不准。你让它"数一下这段有多少个汉字"，它给你的数字经常差十几个，而且每次问都不一样。这不是它笨，是它按 token 工作，不按字工作。所以凡是需要精确计数、精确比较、精确排序的活，都必须交给代码节点，不能交给模型。

这条界线，是低代码平台使用者最该掌握的一条：模型负责"理解"和"生成"，代码负责"计算"和"校验"。用模型算数是这类项目里最常见的低级错误，代价是结果不可信且不可复现。

书里给了这段代码，但没提炼出这条原则。它把代码节点当成一个功能来介绍（"这里可以写代码"），而不是当成一条分工界线（"什么时候必须写代码"）。差别很大：前者你只会照着抄，后者你能自己判断下一个项目要不要写。

同一页还有一句容易被跳过的话：结束节点的回答模式设为"使用设定的内容直接回答"，原因是"前置的消息节点已经将输出的信息发给用户，结束节点仅用于提醒用户任务已经执行完毕"。

这是一个典型的流程细节：消息节点负责说话，结束节点负责收尾，两个都说话用户就会收到两遍。这类"双份输出"的 bug，在可视化工作流里极其常见，因为每个节点看起来都能设一句回复。书里用一句话点掉了，算是有效率。

七、它的短板

第一，第 10 章只剩一页。这不是概括，是我核对过的：p0431 整页内容是"第 10 章 开发内容营销和自媒体运营类 Agent / 10.1 业务场景解读 / 10.1.1 什么是内容营销和自媒体运营类 Agent"，加一段定义——"此类 Agent 的核心能力是内容生成和数据分析，包括但不限于文章、视频脚本、图片及视频……例如搜集热点选题及配图、剪辑视频、自动回复抖音评论等"——然后页面底部就是"下一章"。

也就是说，实战篇号称"5 大场景、11 个 Agent 开发案例"，其中"内容营销和自媒体运营"这一整章，只有标题和一段定义，没有一个案例。而这一章恰恰是自媒体从业者最想看的。我不确定这是纸书如此还是电子版编排缺失，但读者花同样的钱，拿到的是缺一章的书，这是事实。

第二，十一个案例全是单点。一个人、一个对话框、一次成功。没有一个案例涉及：多人同时使用、按角色分配权限、对话历史怎么归档、Agent 出错谁来兜、上线后怎么改提示词而不影响老用户。这些都是"从 demo 到产品"之间必须跨过去的东西，书里一条都没有。

第三，没有一次失败。调试一次通过、试运行一次成功、运行效果一次满意。真实的第一次不会这样。我甚至怀疑这些案例在写作时被反复修剪过，只留下顺利的截图。教程只展示顺风路，会让读者把自己的第一次翻车理解成"我不行"，而不是"这本来就难"。

第四，案例之间的复用没有被抽出来。十一个案例用的是同一套骨架：规划（想清楚要什么）→ 编排（选模式）→ 人设与提示词 → 挂工具/知识库/数据库 → 调参数 → 试运行 → 发布。这个骨架从头到尾没被显式总结过一次。读者读完十一个，得到十一段记忆，而不是一个方法。

公平地说，实战篇的素材质量是全书最高的：提示词结构、参数取值、开场白写法、表格预处理、代码节点用法，这些都是能直接拿去用的东西。问题不在素材，在它没有把素材变成方法。

如果只让我留四页：p0272（温度与 Top P，唯一需要背下来的参数知识）、p0300（开场白的自我降级写法，可直接抄）、p0386（同数据双索引，全书最好的工程判断）、p0390（表格预处理的三条规矩，能省你一周返工）。其余案例快翻即可，套路高度相似。

一句话：这 216 屏给了你十一个能跑起来的演示、几段能直接抄的提示词、一个真正漂亮的索引设计，却没给你任何一次失败、任何一笔成本、任何一个多人场景；它证明了扣子能做这些事，但没证明你的公司能靠这些事省钱——这中间隔着的，正是这本书从头到尾没写的那一章。