读书笔记

《普通人打造AI小团队:通用智能体与企业级智能体搭建》

《普通人打造AI小团队:通用智能体与企业级智能体搭建》书籍封面
作者 金伟
出版社 机械工业出版社
豆瓣评分 暂无评价人数不足
Goodreads 暂无未收录
出版时间
2025年12月
页数
249页
装帧
平装
章数
8章
定价
69.00元
ISBN
9787111796367
我的阅读2026年10月
推荐顺序19

我的读书笔记 · BOOK OVERVIEW

不会编程,也能搭一个 AI 小团队

这是一本写给不会编程的人的智能体入门书。作者金伟说,读者对象是想提效的职场人士、中小企业主和数字化转型负责人、产品经理和业务分析师,目标是一本“看得懂、学得会、用得上”的多智能体开发指南(前言)。全书 8 章,从体验通用智能体 Manus 讲起,再用 Cherry Studio、扣子、AutoGen 这几个不用写代码的平台,一步步搭出单个智能体、知识库、外接工具,最后组成一个多智能体的电商运营团队。

智能体的三件套

  1. 大模型大脑规划:决定下一步做什么
  2. 知识库记忆补上企业私有的知识
  3. MCP 服务手让智能体能操作外部工具

第 6 章

作者对大模型和智能体关系的说法是:大模型是“大脑”,多智能体给大模型加上“手脚”和“团队协作”(前言)。全书反复讲两件事。一是人机协作,不是全托管:智能体能接的活越来越大,但人仍要把任务讲清楚、在关键节点把关。二是人的创造性工作,就是设计智能体。

书里大半篇幅是各平台的注册、界面和配置步骤,产品变化很快,笔记从略,只记做法背后的原理和作者的经验教训。

所谓人类的创造性工作,本质上就是在设计新的智能体。

第1章 1.3 零基础搭建智能体的3个主流平台

第 1 章

认识智能体

从“人主导”到“任务全托管”(第 1 章):作者说,过去用 AI 的方式是“人主导+AI辅助”:人做规划,把某个环节交给 AI,最后人工整合;即使有了 DeepSeek 这类深度推理模型,大多数人仍是这样用。以 Manus 为代表的自主智能体(agent)是“任务全托管”:用户只提需求,任务拆解、调用工具、交付结果都由它自己完成。

用生活场景来比喻的话,传统AI的协作就像一个离不开视线的幼儿,哪怕你只是去趟卫生间都得时刻盯着;而自主智能体则像能独立打酱油的孩子,你只需给他空瓶子和零钱,交代清楚任务,就能安心回到厨房继续炒菜,同时等着他完成任务就行了。

第1章 1.1.1 技术突破点解析

Manus 靠什么做到(第 1 章):作者归结为三项工程能力:

  • 自主规划:用大模型把模糊的需求变成可执行的步骤,例如“帮我制定一个面试时间表”被拆成读取 Excel、安排会议、验证计划可行性等 8 个子任务;
  • 多种工具协同:调用代码生成、浏览器自动化等几十种工具,执行出偏差时按“观察-诊断-修正”的循环自己纠错,还能直接写 Python 程序来执行;
  • 独立的虚拟计算机:每个任务配一台,既安全,又让过程透明,用户随时可以介入。

书中的官方案例是“确定市场上的20家CRM公司并收集他们的口号以及品牌故事”(CRM 即客户关系管理软件)。Manus 先用自己的话复述需求,像一个成熟的员工;再把需求拆成待办清单,粗拆 6 步、再细拆;每完成一个子目标就存档、更新清单;某个网址打不开,它会自己换备用网址或另找信息来源。作者说,在旁边看着它干活,就像老板坐在实习生旁边。

协作,而不是全托管(第 1 章):作者说,“如何在3个月内赚到100万?”这类“许愿式”提示词最常见,结果往往令人失望,交给 Manus 也很难完成。

如果你使用过足够多的大模型和智能体,或许会发现,人类利用自主智能体的核心过程可以抽象为两个字:协作。

第1章 1.2 主流应用类型

首先不能采取全托管的方式。因为任何一个任务都包含着无数细节,除非你亲自完成,否则再智能的自主智能体也无法做到了解每一个细节。

第1章 1.2.2 自主决策类

两类智能体怎么分工(第 1 章):作者把智能体分成两类。SOP 类按人定好的标准操作流程执行(SOP 即标准操作流程);自主决策类连规划也自己做。

相比之下,SOP(基于标准操作流程类智能体)通常比自主决策类智能体运行更快。如果流程本身已经是最优的,那么SOP类智能体反而是最佳选择。

第1章 1.2.1 SOP类

作者按“重要”“紧急”两个维度给出分工:

  • 重要且紧急:人来规划,SOP 类智能体执行;
  • 紧急但不重要:直接交给 SOP 类智能体,因为这类任务最看重稳定和效率;
  • 重要但不紧急:让自主决策类智能体先去探索和执行,人只在最终结果上做粗调。

他举写短视频文案为例:资深运营人员把自己成熟的创作套路写进提示词,提示词本身就成了一个 SOP 类智能体,它出初稿、人再完善。同样的任务交给 Manus:

我们必须承认,Manus缺乏私有数据和独特能力,它的规划基于公开数据,产出的文案可能“看起来不错”,但只会是最大公约数意义上的中庸方案。

第1章 1.2.1 SOP类

适合自主智能体的,是做好了有长期价值、做不好也没什么损失的事,例如把学习资料整理成自己的“专属课程”。用 AI 编程也不能一句话全包:作者主张“宏观架构-微观实现”两层开发,先用概括性的提示词搭整体框架,再逐个模块补细节(第 1 章)。

人的创造性工作:设计智能体(第 1 章):

我先阐述一个观点:大模型是智能体,人类是智能体,传统程序也是智能体。

第1章 1.3 零基础搭建智能体的3个主流平台

作者的理由是:再先进的智能体也需要一个擅长规划决策的“大脑”,而规划逻辑、领域经验、拆解复杂任务的能力,仍要由人来输入。他想让每个人都成为“智能体架构师”。

回到那个核心问题:未来会有多少智能体?个人的创造性空间在哪里?答案很明确——唯一且最重要的创造就是设计智能体本身。

第1章 1.3 零基础搭建智能体的3个主流平台

书里用到三个零代码平台:Cherry Studio 是装在自己电脑上的 AI 客户端,能自建知识库;扣子(Coze)是字节跳动的网页平台,用拖拽的方式编排流程,适合 SOP 类智能体;AutoGen 是开源的多智能体编排系统,适合自主决策类,核心概念是“团队”(第 1 章)。

第 2—3 章

和通用智能体协作

什么时候用 Manus(第 2 章):

Manus和ChatGPT最大的区别就是任务颗粒度不一样。使用Manus的基本原则是:ChatGPT完成不了的任务可以尝试用Manus来完成。

第2章 2.1.2 Manus使用技巧

比如写一份完整的调研报告,用 ChatGPT 要人自己拆成抓数据、定目录、写章节再拼起来;用 Manus,连拆解都由它来做。作者把提示词分两类:已经想清楚怎么做时,写指令式提示词,把步骤交代清楚;没做过这类事,就写许愿式提示词,让 Manus 自己规划,用户还能从它展示的规划过程里学到这类任务的标准做法。他的小技巧是:交任务前先设想人会怎么做,再对照看智能体的每一步,就像带实习生,摸清它的行为模式和能力边界,以后才配合得好(第 2 章)。

指挥一个自主智能体绝不是简单地下达一个指令,而是应该将任务说清楚再交给智能体。

第2章 2.1.2 Manus使用技巧

它为什么什么都能干一点(第 2 章):在特斯拉股票分析的例子里,作者的指令式提示词先对数据采集提出具体要求,再规定市场情绪、技术分析、比较资产、价值投资者、投资论点五项分析。Manus 把任务规划成 14 步,在虚拟机里建一个待办文件,每次只做一个子任务,做完打勾。

为什么Manus虚拟计算机可以完成大部分办公文字信息类任务?一个重要的原因就是Manus虚拟计算机的编程能力达到了工程师的水平。我们可以把它想象成一个用自然语言指挥的工程师。

第2章 2.1.2 Manus使用技巧

作者总结了四点:人的核心作用是写提示词,而且要非常清楚任务细节;规划靠大模型;执行靠写程序,所以能做的事范围很广;规划和编程能力针对特定领域做过微调,执行更可靠(第 2 章)。

三个办公案例(第 2 章):

  • 电商销售额:上传网店上个月的销售表,只给一个目标,“助力下个月的销售额提升10%”。Manus 先写程序做多维统计,再交给大模型找异常、提建议,发现周二销售额普遍较高、周末订单金额偏低等。作者认为这些发现是最大的收获,真正的增长策略还要数据分析和销售人员一起定。
  • 做 PPT:把两个团队的项目截图打包上传,Manus 自己解压、识别图片文字、整理内容、写程序生成 PPT。第一版以文字为主,再提一句“使用上传的截图作为PPT的主要内容”,它就在原有结果上重做。
  • 合同审查:上传 PDF 合同,让它找出所有错误、给出修订版。它像人一样逐页浏览,再用大模型的多模态能力提取文字、找错。

需要注意的是,在这类任务中,我们不应将Manus视为PPT制作高手,而应该主要利用其文档整理能力,目标是完成60%~70%的PPT工作,之后再由人工进行优化。

第2章 2.2.2 PPT与Excel的自动生成

总的来说,Manus在处理文档、PPT和Excel等工作时,100%完成任务并不可能。它更像是一个合格的实习生,负责信息整理、基础编程等工作,并能生成初步草稿,之后再交给人工进行进一步处理。

第2章 2.2.2 PPT与Excel的自动生成

三种协作模式(第 3 章):

实际上,Manus输出的质量取决于两个因素:一是输入的数据质量,二是任务的规划水平。

第3章 3.1 提示词的优化方法

作者借用沟通理论里的“乔哈里视窗”,分三种情况:

  • 我们不擅长、它擅长:让 Manus 主导规划。这时要尽量给足文档,聊天截图、数据表、Word、PDF 甚至音视频都行,提示词只讲清两件事:输入是什么,输出要什么形式。作者让它写 5 篇 MCP 技术公众号文章,没有只说“帮我写5篇MCP技术文章”,而是先自己写好大纲,附上自己读过的参考文献,要求不改大纲、只扩写。结果第一篇没有信息错误,人工润色就能发。
  • 我们擅长、它不擅长:由人主导规划。只说“我想开发一个类似体重小本的App,请协助完成产品设计”,Manus 只交出一份文字文档;换成产品经理写的分步骤提示词(用户体验分析、界面规划、高保真界面、网页原型),才得到可以点击的原型。
  • 双方都没经验:一起摸索。先让它出文字版,人审阅修改后,再让它做成网站。作者认为这是普通用户的最佳选择,代价是多花一些算力。

想要得到更专业的结果,需将Manus使用者的角色设定为专业的“产品设计师”,同时将使用Manus的模式由“交给它来做”切换到“指导它来做”。

第3章 3.1.2 由人主导规划

与大模型的使用类似,Manus这类自主智能体只是让任务的颗粒度变大了,但要让它一次性给出完美的结果仍然非常困难,主要是因为很难在一次交互中描述清楚所有细节。

第3章 3.1.3 共同协作

边界感(第 3 章):作者让 Manus“收集中国1000家中小外包公司的网站、邮箱和电话”,还特意加了一句“全力以赴,不要偷懒”。它找到 100 多家后就停住了,界面上说会继续,实际没有继续。作者的两个办法:把任务拆小,比如一次只查一个地区;卡住了就下载已有结果,人工整理后再开新任务。

即使一个任务失败了,它的中间结果仍然具有利用价值,可以作为新任务的输入数据。

第3章 3.2.1 流程卡死的急救方法

对人机配合要求高的任务,可以在提示词里预先留出人工环节。作者请 Manus 陪他读智能体论文,提示词里写明“我自己分析后告诉你网址”,Manus 就在这一步停下来,等他选好论文搜索网站再继续。

总体而言,目前的自主智能体能够实现任务级别的自主规划与执行,但尚无法完成整体项目,大多数情况下仍需要人工介入。

第3章 3.2.2 预设人工接管方案

作者还介绍了智谱的 AutoGLM 沉思:它不写程序,而是操作用户自己电脑上的浏览器去收集资料,流程是大模型规划、操作浏览器采集、大模型分析,适合从网上收集、整合信息的日常办公(第 3 章)。

第 4 章

智能体怎么运行:思考和行动

为什么要懂原理(第 4 章):

就像大模型不会只存在一家公司一样,Manus这类通用智能体平台可能仅适用于日常办公,很难深入到公司特定的业务逻辑中。

第4章 4.1 智能体的核心运行原理

作者预计,未来公司里的 IT 系统一定是多智能体协作,每家公司都需要自己的智能体平台,所以懂原理、会搭建会成为必备技能。

一个循环(第 4 章):Manus 不开源,作者拿开源的 OpenManus 来拆。它用的是 ReAct(Reasoning-Acting,思考-行动)框架:“思考”阶段让大模型分解任务、选择下一步用哪个工具;“行动”阶段去调用工具;工具的结果再交回给大模型,循环往复,直到任务完成或失败。

此处的Manus智能体本质是让大模型做决策,决策内容是下一步用什么工具,直到大模型决策用Terminate工具终止程序。

第4章 4.1.1 思考-行动框架

Manus 的创新在“行动”阶段:它用 CodeAct 的思路,把可执行的代码当作工具。程序报错时,它会读错误信息、自己改代码、重新执行(第 4 章)。

在“行动”阶段采用自主编程执行机制的好处是:针对任务拆分,不仅可以通过自主编写代码来完成,也可以通过调用现有的工具能力来完成。在这个过程中,程序代码实际上充当了各个工具的黏合剂。

第4章 4.1.2 智能体的代码生成原理

零代码搭三个智能体(第 4 章):作者用 Cherry Studio 按 SOP 拆出三个智能体:信息采集(理解需求、联网抓网页)、数据分析(读懂上传的数据、用常见方法分析)、数据可视化(借 QuickChart 这类图表网站,把数据变成图)。每个都先想清楚:输入什么、输出什么,“思考”和“行动”分别由谁来做。不熟悉数据分析,可以先让一个专门写提示词的智能体出草稿,再自己改得更准,不要照搬。

零基础搭建智能体的关键在于智能体设计,而非具体的代码编程。通过这个过程,读者可以很好地了解如何设计一个属于自己的智能体。

第4章 4.2 用Cherry Studio搭建智能体

SOP智能体的核心要点是设计清楚这些智能体的输入和输出。具体的任务拆解和执行可以交给大模型和相关工具。

第4章 4.2.2 信息采集智能体:网页操作助手

第 5 章

知识库:智能体的记忆

为什么需要知识库(第 5 章):作者问默认智能体“金伟是谁”,因为他不是公众人物,网上查不到;把他的简历 PPT 放进知识库后,智能体就能据此回答。

让智能体知道这个准确的私有信息,正是知识库的价值所在——通过补充专有数据,使大模型具备企业所需的特定知识,从而让智能体真正能在实际业务场景中发挥作用。

第5章 5.1.1 知识库创建与基础查询

构建专有知识库的质量主要取决于数据质量,所以要先对数据做好整理和分类。

第5章 5.1.1 知识库创建与基础查询

没有现成文件,就专门写知识文档,先分类(以金融科技为例:支付、区块链、风控、监管合规、金融产品),再用统一格式整理。

知识库怎么查(第 5 章):用户提问后,知识库按匹配程度找出相关的知识片段,再把这些片段塞进提示词,交给大模型回答。匹配靠的是向量查询:文档被切成小段,每一段和用户的问题都由嵌入模型转成一组数字(向量),算相似度,越像越靠前。

由此有三类优化:

  • 文档格式:整理成一问一答的文档,比没整理的效果好;文字版好于图片,PDF 要文字版,不要扫描版。
  • 分段:每段多大(M)、最多交给大模型几段(N)、相邻两段重叠多少,都要反复测。重叠是为了不把一句完整的话切断:一段讲完糖尿病症状、下一段才讲治疗方法,用户问“糖尿病应该如何治疗?”时,可能只查到症状那段。
  • 排序:按相似度取前几段不一定最好,可以再加一个重排模型重新排序。

M和N越大,则提交给大模型的数据量越大;M和N越小,则越有可能导致相关知识丢失。其具体设置需要结合知识库测试反复调整优化。

第5章 5.1.2 知识库查询优化

实际上,知识库的优化不是一次性就能完成的。这些基础操作也许能达到90%的准确率,但要将准确率从90%提升到99%,还需要更多的技巧和经验。

第5章 5.1.2 知识库查询优化

测试与改进(第 5 章):搭好后要准备一组测试问题,看两点:回答是否恰当用上了知识库里的知识,整体质量是否接近人的水平。

当在测试中发现问题时,如何改进知识库?通常的解决方案不是简单地调整知识库参数,而是针对特定问题专门建立知识条目。

第5章 5.1.3 知识库测试与改进

向量查询不擅长处理知识之间的关联。作者举了两条贷款规则:一位首次申请、年收入 15 万元、信用评分 750 分的客户,按规则一最高可贷 50 万元且无须担保人,按规则二上限是年收入的 3 倍即 45 万元、必须有担保人。知识库可能只查到其中一条,或者两条都查到却不说哪条优先。办法有三:定期回顾、为特殊情况补充知识;切分时保留段落之间的上下文;先粗查找到主题,再细查取完整上下文。

上线以后(第 5 章):从 90% 到 99%,主要靠上线后的反馈和更新。用户反馈的问题分三类:内容不准或过时、内容缺失、对功能的建议。作者建议把知识库按模块分开(常见问题、产品指南、故障排除),哪块出问题就处理哪块;并善用人工接管的记录。

既然一个问题需要人工接管,那它大概率存在某个知识库问题。更进一步说,对于知识准确性要求高的场景,应该在用户使用过程中智能化告知其知识库的特性,不应该过度承诺。

第5章 5.2 知识库应用中的用户反馈流程

书中的例子:某电商平台发现很多用户查完退换货政策仍要找人工客服,查对话记录才知道大家困惑的是跨境商品,于是把普通商品和跨境商品的政策分开写、补上操作流程,转人工的比例明显下降;某在线问诊平台查症状时先提示“仅供参考”,不直接下诊断,症状严重时马上建议问诊或就医。

更新分两种:主动更新是按计划或规则提前改,比如每发布一款新品就补功能介绍、使用说明和常见问题;被动更新由用户反馈触发(第 5 章)。

被动更新虽然能解决用户实际遇到的问题,但往往具有滞后性,且无法覆盖所有潜在的知识缺口。

第5章 5.2 知识库应用中的用户反馈流程

第 6 章

MCP:智能体的手

MCP 是什么(第 6 章):MCP(Model Context Protocol,模型上下文协议)是一套标准,规定外部程序怎样接到大模型上。过去别人想用你的数据服务,要按你的接口文档专门开发插件;有了统一协议,服务方按协议做一次,所有支持 MCP 的 AI 客户端都能直接接入,用户也不用在不同软件之间复制粘贴。

MCP的诞生源于大模型的一个根本性局限——它们无法直接与外部世界交互。这就像一个博学多才的顾问被困在一个没有窗户的房间里,只能通过有限的对话来交互。

第6章 6.1.1 什么是MCP

简而言之,如果将大模型视为智能体的“大脑”,那么知识库就是其“记忆”,MCP服务就是智能体的“手”。

第6章 6.1.1 什么是MCP

作者给智能体接上一个网页抓取服务,前后不到一分钟。

可以说,未来的智能体开发的主要工作在于为智能体配置合适的MCP服务,通过组合这些MCP服务来实现单个智能体能力的提升。

第6章 6.1.2 接入MCP服务

无论是自主智能体还是SOP类智能体,实际上都是人类对规划和控制权利的让渡。目前大部分智能体仍然需要人机协作,而未来大部分智能体将会是自主决策类智能体,当然,实际上只是任务颗粒度变大而已。

第6章 6.1 MCP快速入门

做一个英语教案智能体(第 6 章):作者从三方面设计:规划,把老师已有的教案模板写进提示词,智能体只在细节上扩充;行动,用 MCP 生成插图和配音;记忆,把教材、老师的经验和其他优秀教案放进知识库。

智能体只是提升教案生成的效率,整体的思路还是通过老师的教案模板来落实。

第6章 6.2.1 教案智能体分析与规划

挑 MCP 服务的办法:先想清楚要补什么能力,用关键词搜出候选,读介绍、案例和其他用户的评价,挑几个实测。作者也解释了调用原理:客户端把每个工具的说明附在提示词里交给大模型;大模型自己不能调用工具,只能用文字告诉客户端该调用哪个工具、参数是什么,再由客户端去执行。

调试中他踩了两个坑。一是要智能体一次写完教案再配多张图,怎么改提示词都不行,把流程拆成生成教案和配图两步才成功。二是图片总显示不出来,他一步步查调用记录,最后发现是客户端把图片网址截短了,改提示词才解决(第 6 章)。

在实测中,多次调整提示词也无法实现。其原因在于整个Workflow任务过于复杂,大模型难以一次全部规划完。所以才对Workflow做了拆分,让每次只专注于一个任务,降低大模型规划的复杂度。

第6章 6.2.2 基于MCP服务的智能交互与个性化调整

实际上,如果不熟悉从提示词编写到大模型规划,从工具调用再到Cherry Studio显示的全流程,根本无法发现并解决这一问题。

第6章 6.2.2 基于MCP服务的智能交互与个性化调整

第 7 章

工作流:把经验变成流程

SOP 类智能体的上限(第 7 章):

SOP实际上采用的是现成的人类经验,智能体只是用工具提高了SOP的执行效率,其整体决策上限也取决于人类的既往经验上限。

第7章 7.1 扣子平台快速入门

在扣子平台上,工作流就是智能体的 SOP。作者拆解了平台自带的“智能客服助手”:用户的问题从“开始”节点进来,先识别意图、分成两类,产品问题先改写再查知识库,其他问题走通用回答,最后把问答记到表格里。每个节点用提示词配置,都能单独调试。

总之,一个扣子工作流就是一个顺序执行的程序,每次用户提问都会经过这个工作流,只是扣子平台提供了零代码的节点模块,让用户得以用零代码的编辑工作流构建智能体。

第7章 7.1.3 知识库配置

化学小助手(第 7 章):作者给初中生做了一个化学小助手,含两个工作流:一个结合教材知识库,用初中生听得懂的口吻回答化学问题;一个把化学反应公式生成为三维分子的网页,再用插件发布成网址。他强调先把要讲的化学知识和交互逻辑梳理清楚,再动手。

注意:这里的工作流描述非常关键,实际上这个工作流的描述和智能体的系统提示词会共同组成智能体的“思考”部分,让智能体遇到特定的用户问题可以准确调用这个工作流。

第7章 7.2.1 实验过程分解与脚本编写

在给“化学小助手”智能体添加工作流之前,需要先单独对“3Dmol”和“html2url”这两项技术调研,保证单独运行没问题之后再集成到“化学小助手”智能体的工作流中。

第7章 7.2.2 可视化元素设计与制作

测试时问“给我一个二氧化碳化学反应”,智能体先用第一个工作流讲知识,发现回答里有反应式,又调用第二个工作流,在末尾附上可视化链接。

对于“化学小助手”智能体来说,“workflow1”和“workflow2”只是智能体的两个内部工具,这两个工具的组合使用则由智能体完成。

第7章 7.2.2 可视化元素设计与制作

第 8 章

多智能体团队

像组建一个团队(第 8 章):AutoGen 的三个核心概念是团队(Team)、员工(Agent)和能力(Tool):一个团队就是一个多智能体系统,由多个员工组成,每个员工有一项或几项能力。作者用人类团队来类比:角色有主管(Manager)、专家(Expert)、执行者(Executor);记忆有三种,当前对话的上下文像白板上的讨论要点,长期知识库像团队共享的文档库,任务执行的记录像项目甘特图。需要跨部门就设多个专家加一个协调主管,遇到争议可以设投票权重,作者称之为“人类协作数字化”。

1)每个智能体都是大模型的“职业化分身”。通用GPT像刚毕业的大学生,而角色定义给它加载了“岗位说明书”,例如,技术顾问在回复时会自动调用产品手册知识库。

第8章 8.1.4 多智能体协作

先规划、后搭建(第 8 章):

多智能体团队的规划过程是一个从上至下的过程,先定义团队(对应AutoGen里的团队,即“Team”),再定义员工(对应AutoGen里的智能体,即“Agent”),最后定义能力(对应AutoGen里的工具,即“Tool”)。

第8章 8.2.1 需求分析与智能体团队规划

而多智能体“团队”的构建过程则反过来,先构建单项能力并测试,再定义员工(添加能力),最后定义团队(加入员工协作)并进行测试。

第8章 8.2.1 需求分析与智能体团队规划

作者的分工是:AutoGen 负责定义团队和协作规则,每个员工的具体本事用扣子平台做好,再通过程序接口接进来。

基于Cherry Studio平台或扣子平台搭建单智能体的过程像是构建某个单独员工的专业能力,而基于AutoGen搭建多智能体系统则像构建一个团队,这个过程更关注的不是员工的个人能力,而是定义团队的整体能力。

第8章 8.2.2 接口机制设计:基于扣子平台

团队怎么协作(第 8 章):作者从 AutoGen 自带的网页团队模板入手:一个上网查资料的员工,一个负责检查结果、决定继续还是收工的主管,一个必要时找人类补充信息的代理。团队每一步只让一个员工干活,由一个协调者根据到目前为止的对话记录,挑下一个该谁上;主管认为完成了,就发出结束信号。

需要特别说明的是,这种选择机制具有动态演变的特性,这与类似扣子工作流的固定顺序执行逻辑存在本质区别。

第8章 8.4.1 利用模板构建

电商运营团队(第 8 章):作者规划了一个做爆品运营和爆款短视频的团队,分三个小组:选品小组(采集电商热销数据、分析爆品),短视频小组(提取爆款视频文案、仿写、找素材合成视频),数据小组(存取数据)。他先只“招”一个采集员工,再逐步加入运营主管、数据专员、爆品分析员。

测试中出了岔子:让团队推荐爆款,它却拿“爆款”当关键词去采集数据。

在图8-34所示的异常情况测试中,爆品相关任务同样由系统自动调用数据采集工具执行,这种现象其实反映了团队角色职能边界界定不够清晰的问题。

第8章 8.5.2 打造爆品分析智能体

他的修改:新增专门的爆品分析员;每个员工的提示词写清它和谁配合;团队提示词写清每个员工的定位;主管只负责检查和判断。

在运营主管智能体里,明确了其定位是负责结果验证和判断,具体执行都依赖其他智能体,这可以避免运营主管智能体出现主动抢活的情况。

第8章 8.5.2 打造爆品分析智能体

改完后,在没有预先规定任何步骤的情况下,新增关键词、按关键词抓取数据、做一次爆品抓取、分析潜在爆品四项任务,都交给了对的员工。作者提醒,书里的提示词都是改好的最终版,实际搭建要不断测试、细调(第 8 章)。