1. 为什么我把COZE作为智能体搭建的首选平台第一次接触COZE是在一个需要快速验证AI智能体产品逻辑的项目里。当时团队只有三个人一个后端、一个前端、加上我负责产品和技术方案。老板给的deadline是两周要做一个能自动处理用户咨询、能查数据库、还能生成结构化报告的智能体原型。如果用传统开发方式光是把大模型接入、写意图识别、做多轮对话管理、再对接内部API两周连联调都不够。后来一个做AI产品的朋友甩给我一个COZE的链接说“你先玩玩这个别急着写代码”。结果我用了一个下午就把核心流程跑通了。COZE本质上是一个AI智能体搭建平台你可以把它理解成一个“乐高式”的AI应用工厂。它把大模型调用、提示词编排、插件接入、工作流设计、知识库管理、多轮对话状态维护这些原本需要写大量代码才能实现的能力全部做成了可视化配置项。你不需要懂Transformer架构不需要会写Python装饰器甚至不需要理解什么是function calling的底层协议只要能把业务逻辑拆清楚就能在COZE上搭出一个能跑起来的智能体。这篇文章适合三类人看。第一类是完全没接触过AI智能体搭建的产品经理或运营同学想快速验证一个想法不想等研发排期。第二类是有一定技术基础但没深入做过AI应用的后端或全栈工程师想了解COZE这类平台的能力边界和底层逻辑。第三类是在做企业级AI应用选型的技术负责人想搞清楚COZE到底能扛多重的活什么时候该用它什么时候该自己写代码。我后面会从整体设计思路、核心模块拆解、实操搭建过程、常见问题排查这几个维度把COZE平台的使用经验完整地摊开来讲。所有内容都基于我实际搭建过十几个智能体的经验包括踩过的坑和后来总结出来的技巧。2. COZE平台的整体设计与核心模块拆解2.1 智能体、工作流、插件、知识库四件套的关系COZE的产品结构可以用一个类比来理解。把智能体想象成一家餐厅用户进来点菜智能体负责接待和协调。工作流是后厨的流水线把一道菜的各个工序串起来。插件是厨房里的各种设备比如烤箱、榨汁机、切菜机每个设备只干一件专业的事。知识库是餐厅的菜谱库和食材档案智能体需要查资料的时候就来这里翻。这四者的关系不是并列的而是有明确的层级。智能体是最终对用户暴露的入口它负责理解用户意图、维护对话状态、决定什么时候调用工作流、什么时候直接回答。工作流是智能体内部的一条确定性执行链路一旦触发就按预设的节点顺序执行适合处理步骤明确、需要多步操作的任务。插件是工作流或智能体可以直接调用的原子能力比如搜索、计算、调用外部API。知识库则是给智能体提供私有领域知识的存储和检索层通常以向量数据库的形式存在。我见过很多新手一上来就猛建工作流结果智能体里塞了七八条工作流每条工作流又调了五六个插件最后调试的时候根本不知道问题出在哪一层。正确的做法是先想清楚这个任务是需要灵活对话还是需要确定性执行如果需要灵活对话优先用智能体的提示词加知识库来解决。如果需要确定性执行比如“查订单然后发邮件然后记录日志”那就用工作流。插件只在需要外部能力的时候才引入不要为了用插件而用插件。2.2 提示词在COZE里的真实作用边界提示词在COZE里扮演的角色和很多人想象的不太一样。在纯聊天场景里提示词确实决定了智能体的性格、语气、回答风格。但在COZE这种平台里提示词更多是承担“路由”和“约束”的功能。举个例子我在做一个制度条例学习助手的时候智能体的提示词里写了这么一段“当用户询问具体制度条款时优先从知识库检索当用户要求对比两个制度时调用对比工作流当用户只是打招呼或闲聊时直接回复不要调用任何工具。”这段提示词的作用不是让模型“更聪明”而是给模型一个明确的分支判断逻辑减少它乱调工具的概率。COZE的提示词支持变量插入比如{{user_query}}、{{knowledge}}、{{workflow_output}}这些变量会在运行时被实际值替换。这个机制很关键因为它让提示词从静态文本变成了动态模板。我通常会把工作流的输出作为变量注入到智能体的提示词里让智能体基于工作流的结果做二次加工。比如工作流返回了一段JSON格式的制度条款智能体拿到之后再用自然语言总结给用户。还有一个容易忽略的点COZE的提示词是有长度限制的虽然官方没有明确说上限但实测下来超过3000字之后模型的遵循度会明显下降。所以提示词要精炼把最重要的约束放在最前面和最后面中间放具体的业务逻辑说明。2.3 工作流的节点类型与执行逻辑COZE的工作流节点类型不算多但组合起来能覆盖大部分场景。核心节点包括开始节点、大模型节点、插件节点、知识库检索节点、条件判断节点、代码节点、变量节点、结束节点。开始节点定义输入参数这些参数可以从智能体传入也可以在工作流被直接调用时传入。大模型节点是工作流里最灵活的节点你可以给它单独的提示词让它处理一段文本、做分类、做提取、做总结。插件节点调用外部能力比如搜索、天气、数据库查询。知识库检索节点从指定的知识库里召回相关文档片段。条件判断节点根据变量的值决定走哪条分支。代码节点允许你写一小段Python或JavaScript来处理数据格式转换、字符串操作、数学计算。变量节点用来在流程中传递和修改状态。结束节点定义输出。工作流的执行是串行的但通过条件判断节点可以实现分支通过并行节点可以实现简单的并发。我实测下来一个工作流里节点数量控制在15个以内比较稳妥超过20个之后调试成本急剧上升而且执行耗时也会明显增加。如果业务逻辑确实很复杂更好的做法是拆成多个工作流用智能体来编排调用顺序。2.4 插件系统的能力边界与接入方式COZE的插件系统是我觉得最实用的部分。官方插件市场里有很多现成的能力比如网页搜索、图片生成、代码执行、文档解析。但真正让COZE强大的是自定义插件的能力。自定义插件的接入方式有两种。一种是通过API定义你提供一个符合OpenAPI规范的接口描述文件COZE会自动解析出插件的输入输出参数然后在工作流里就可以像调用内置插件一样调用你的API。另一种是通过代码插件直接在COZE的代码编辑器里写一段函数平台负责运行环境。我大部分时候用第一种因为这样可以把已有的后端服务直接暴露给智能体不需要重写逻辑。插件的输入输出都是JSON格式这点很重要。你在设计插件的时候输入参数要尽量扁平化不要嵌套太深因为大模型在填充参数的时候对嵌套结构的理解能力有限。输出也尽量结构化方便后续节点解析。我踩过一个坑插件返回了一个三层嵌套的JSON结果下游的大模型节点解析的时候经常漏字段。后来改成扁平结构问题就消失了。3. 从零搭建一个制度条例学习助手的完整实操3.1 需求拆解与智能体能力规划这个制度条例学习助手的场景是这样的公司内部有几百份制度文件员工想查某个规定的时候不需要去翻文件夹直接问智能体就行。智能体要能做到回答具体条款、对比不同制度、解释制度背后的逻辑、引导员工找到相关制度。我把这个需求拆成了四个能力模块。第一是知识检索从制度库里找到相关条款。第二是条款解释把生涩的制度语言翻译成大白话。第三是对比分析当员工问“A制度和B制度在报销标准上有什么区别”时能拉出两个制度的相关条款做对比。第四是引导推荐当员工的问题比较模糊时能追问澄清或者推荐相关制度。对应到COZE的配置上知识检索用知识库节点条款解释用大模型节点加提示词对比分析用工作流加条件判断引导推荐用智能体的多轮对话能力。这个拆解过程很关键它决定了你后面搭出来的东西是清晰还是混乱。3.2 知识库的创建与文档处理要点COZE的知识库支持上传多种格式的文档包括PDF、Word、TXT、Markdown。我上传了大概200份制度文件总体积在500MB左右。上传之后COZE会自动做分段和向量化这个过程大概花了十几分钟。这里有几个实操要点。第一文档在上传前最好做一次预处理。我把所有制度文件里的页眉页脚、水印、无关的表格都清理掉了只保留正文。这样能显著提高检索的准确率。第二分段策略很重要。COZE默认的分段是按固定字数切分但制度文件往往有明确的章节结构我手动把每份制度按“章-节-条”切成了独立的小文档再上传检索效果比整份上传好很多。第三知识库的召回数量可以调默认是3条我调到了5条因为制度条款经常需要交叉引用多召回几条能让大模型有更完整的上下文。还有一个细节COZE的知识库支持设置相似度阈值。我设的是0.75低于这个分数的片段不会被召回。这个值不能设太高否则会漏掉相关条款也不能设太低否则会引入大量噪音。0.7到0.8之间是比较稳妥的范围。3.3 工作流搭建对比分析功能的实现对比分析功能是我花时间最多的部分。用户问“差旅制度和招待制度在审批流程上有什么区别”智能体需要先识别出这两个制度名称然后分别检索两个制度的相关条款最后做对比总结。工作流的节点编排是这样的开始节点接收用户问题第一个大模型节点做意图识别和实体提取输出两个制度名称和对比维度。然后接一个条件判断节点如果提取到了两个制度名称就走对比分支如果只提取到一个就走单制度解释分支如果什么都没提取到就走引导分支。对比分支里我用了两个并行的知识库检索节点分别检索两个制度的相关条款。然后接一个代码节点把两个检索结果合并成一个结构化的JSON。再接一个大模型节点提示词里写清楚“请从审批流程、审批时限、审批权限三个维度对比以下两个制度条款”把合并后的JSON作为变量注入。最后结束节点输出对比结果。这里有个坑并行节点的输出顺序是不确定的所以代码节点里不能假设哪个结果先到。我的做法是给每个检索节点的输出打上标签比如source_a和source_b然后在代码节点里根据标签来合并。3.4 提示词工程在COZE里的落地写法智能体的系统提示词我改了大概十几版最后稳定下来的结构是这样的# 角色 你是公司制度条例学习助手负责帮助员工理解和查询公司各项制度。 # 能力 1. 当用户询问具体制度条款时从知识库检索并回答。 2. 当用户要求对比两个制度时调用对比分析工作流。 3. 当用户问题模糊时主动追问澄清。 4. 当用户询问制度之外的问题时礼貌拒绝并引导回制度话题。 # 约束 - 回答必须基于知识库内容不要编造条款。 - 如果知识库没有相关内容明确告知用户并建议咨询相关部门。 - 回答时先给出结论再引用具体条款编号。 - 语气正式但不生硬像一位耐心的HR同事。 # 输出格式 - 条款引用格式【制度名称】第X条第X款 - 对比分析用表格呈现这个提示词的关键在于把“什么时候做什么”写清楚了。COZE的智能体在运行时会把这个系统提示词和用户输入一起送给大模型大模型根据提示词里的分支逻辑来决定下一步动作。实测下来这种结构化的提示词比一大段自然语言描述的遵循度高很多。3.5 插件接入让智能体能查外部数据制度助手本身不太需要外部插件但我在另一个项目里做了一个简历筛选工作流用到了自定义插件来查数据库。这里顺便说一下插件接入的实操。我在COZE里创建了一个自定义插件接口定义是这样的输入参数是candidate_id输出参数是candidate_name、skills、experience_years、education。接口地址指向我们内部的一个REST API。COZE会自动生成一个测试用例你可以在平台上直接测试插件是否连通。插件接入工作流之后大模型节点可以根据上下文自动填充candidate_id这个参数。但这里有个技巧如果candidate_id是从用户输入里提取的最好先用一个大模型节点做实体提取把提取结果作为变量传给插件节点而不是让插件节点直接从用户输入里猜。这样准确率高很多。4. 实操过程中踩过的坑与排查技巧4.1 智能体不调用工作流的常见原因这是新手遇到最多的问题明明配了工作流但智能体就是不走工作流直接自己回答了。原因通常有三个。第一个原因是提示词里没有明确告诉智能体什么时候该调用工作流。大模型默认倾向于自己回答除非你明确指示它“遇到X情况必须调用Y工作流”。我的做法是在提示词的能力部分用“当...时调用...”的句式写清楚触发条件。第二个原因是工作流的描述不够清晰。COZE里每个工作流都有一个描述字段这个描述会作为工具说明传给大模型。如果描述写的是“处理制度相关请求”大模型很难判断什么时候该用。改成“当用户要求对比两个制度的条款差异时调用此工作流”调用率立刻上去了。第三个原因是工作流的输入参数定义有问题。如果工作流需要一个必填参数但智能体无法从对话中提取到这个参数它就会放弃调用。解决办法是把参数设为可选或者在工作流内部加一个默认值处理逻辑。4.2 知识库检索不准的优化思路知识库检索不准的表现是用户问A条款智能体返回了B条款的内容。排查思路是这样的。先看分段是否合理。如果一份制度文件被切成了很多碎段每个段落的上下文不完整检索出来的片段可能缺少关键信息。我通常会把每份制度按条款切分每个条款作为一个独立文档这样检索粒度更细。再看相似度阈值是否合适。阈值太高会漏召回太低会引入噪音。我一般先用0.7跑一批测试问题看召回结果的相关性再微调。还有一个容易被忽略的点知识库的embedding模型选择。COZE默认用的模型对中文的支持还可以但如果你的制度文件里有大量专业术语可以考虑在文档里加一些同义词标注或者在检索前先用大模型做一次query改写把用户的口语化问题改写成更接近制度语言的查询。4.3 工作流执行超时的处理方案工作流节点多了之后执行时间会变长。COZE对工作流的执行时间有限制超时之后会直接失败。我遇到过一次一个包含三个大模型节点和两个插件节点的工作流平均执行时间在25秒左右偶尔会超过30秒的限制。优化方案有几个。第一把不必要的大模型节点合并。比如意图识别和实体提取可以放在同一个大模型节点里完成不需要拆成两个。第二插件节点的调用尽量并行。COZE支持并行节点把没有依赖关系的插件调用放在并行分支里能省不少时间。第三如果工作流确实很复杂考虑拆成两个工作流用智能体来串联这样每个工作流的执行时间都在限制之内。4.4 常见问题速查表问题现象可能原因排查方向解决方案智能体不调用工作流提示词未明确触发条件检查系统提示词的能力描述用“当...时调用...”句式明确触发条件知识库检索结果不相关分段粒度过粗或阈值不当查看召回片段内容按条款切分文档调整相似度阈值到0.7-0.8工作流执行超时节点过多或串行调用查看工作流执行日志合并大模型节点并行化插件调用拆分工作流插件调用失败参数填充错误或接口不通在插件测试页单独测试用大模型节点做实体提取后再传参智能体回答编造条款提示词约束不够强检查提示词的约束部分明确写“必须基于知识库内容不得编造”多轮对话丢失上下文变量未正确传递检查对话变量配置在智能体里开启多轮对话记忆用变量存储关键信息5. COZE与其他方案的对比与选型建议5.1 COZE、Dify、n8n的定位差异这三个平台经常被放在一起比较但它们的定位其实差别很大。COZE是面向AI智能体的一站式搭建平台强项在于大模型能力的封装和对话管理适合做面向C端或内部员工的对话式AI应用。Dify更偏向LLM应用开发框架提供了更灵活的API编排和RAG能力适合有一定技术能力、需要深度定制RAG流程的团队。n8n是通用工作流自动化工具强项在于系统集成和定时任务AI能力只是它的一部分。我个人的选型逻辑是这样的如果核心需求是做一个能对话、能查知识库、能调几个API的智能体COZE是最快出成果的。如果需要对RAG的检索策略做深度定制比如自定义embedding、重排序、多路召回Dify更合适。如果需求主要是系统间的数据流转和自动化AI只是其中一环n8n更趁手。5.2 什么时候该从COZE迁移到自研COZE不是万能的。我总结了几条需要从COZE迁移到自研的信号。第一当你的智能体日活超过一定量级COZE的按量计费模式成本会变得很高自研用开源模型加自己的推理集群可能更划算。第二当业务逻辑复杂到COZE的工作流节点数经常超过30个调试和维护成本已经超过自研的开发成本。第三当你有严格的数据合规要求知识库和对话数据不能放在第三方平台。第四当你需要对模型的推理参数做细粒度控制比如temperature、top_p、frequency_penalty的逐请求调整COZE的封装层会限制你。但迁移不是一蹴而就的。我的建议是先用COZE把产品逻辑跑通验证用户需求真实存在再考虑自研。很多团队一上来就自研结果花了三个月做出来的东西用户根本不用。5.3 企业级部署的注意事项如果要在企业内网部署COZE目前官方提供的是SaaS版本本地化部署需要走企业版方案。我参与过一次企业版部署的评估核心关注点是数据隔离、权限管理和审计日志。数据隔离方面要确认知识库和对话数据是否存储在独立实例里是否支持加密存储。权限管理方面要确认是否支持按部门、按角色分配智能体的访问权限。审计日志方面要确认是否记录每次对话的输入输出、调用了哪些工作流和插件方便后续合规审查。还有一个实际的问题企业内部的API接口往往有复杂的认证机制比如OAuth2.0、API Key轮换、IP白名单。在COZE里配置自定义插件的时候这些认证信息需要妥善管理。我的做法是把认证逻辑封装在插件后端COZE这边只传业务参数不传认证信息。6. 一些让我少走弯路的实操心得6.1 先跑通最小闭环再扩展我见过太多人一上来就设计一个功能极其复杂的智能体结果卡在某个节点上好几天最后失去信心。正确的做法是先做一个最小闭环一个智能体、一个知识库、一个简单的工作流能回答一个具体问题就行。跑通之后再逐步加插件、加分支、加多轮对话。我在做制度助手的时候第一版只做了“查条款”这一个功能。用户问“年假有多少天”智能体能从知识库里检索到相关条款并回答。这个版本我花了一个小时就搭完了。然后在此基础上加了对比功能、引导功能、解释功能。每加一个功能都确保之前的能正常工作。6.2 用测试用例驱动调试COZE的调试界面可以让你直接和智能体对话但手动测试效率很低。我的做法是准备一组测试用例大概20到30个问题覆盖各种场景正常查询、模糊查询、对比查询、无关问题、多轮追问。每次修改提示词或工作流之后把这组问题跑一遍看通过率。这组测试用例我放在一个表格里每行是一个问题、期望的输出类型、实际输出、是否通过。跑了几轮之后哪些提示词需要改、哪些节点需要调一目了然。6.3 版本管理与回滚COZE支持智能体的版本发布但很多人不重视这个功能。我强烈建议每次修改之后都发布一个新版本并在版本描述里写清楚改了什么。这样当新版本出问题的时候可以一键回滚到上一个稳定版本。我吃过一次亏改了一版提示词测试的时候只测了两个问题觉得没问题就发布了。结果上线之后发现多轮对话场景下智能体会丢失上下文。幸好有版本记录回滚到上一版只花了一分钟。6.4 关注执行日志里的隐藏信息COZE的执行日志里有很多有用的信息但容易被忽略。比如每个节点的执行耗时、大模型节点的token消耗、知识库检索的召回片段和相似度分数。这些信息在优化性能的时候非常关键。我通过日志发现某个大模型节点的平均耗时是8秒占了整个工作流的一半时间。后来把那个节点的提示词精简了三分之一耗时降到了5秒。还有一次日志显示知识库检索的相似度分数普遍在0.6左右说明阈值设高了调低之后召回率明显提升。6.5 不要忽视冷启动问题智能体刚上线的时候知识库的检索效果往往不如预期。这不是因为配置有问题而是因为用户的实际提问方式和你的测试问题不一样。我的做法是上线第一周每天看对话日志把用户问得最多但回答不好的问题整理出来针对性地补充知识库内容或调整提示词。还有一个技巧在智能体的欢迎语里引导用户怎么提问。比如“你可以问我年假有多少天差旅报销标准是什么”这样用户的问题会更规范检索准确率也会更高。6.6 关于COZE生成视频能力的实测COZE本身不直接生成视频但可以通过插件调用视频生成能力。我试过用工作流串联“文本生成脚本 - 调用视频生成插件 - 返回视频链接”这个流程。实测下来生成一段15秒的短视频大概需要2到3分钟画质和连贯性取决于调用的视频生成模型。如果只是做简单的动画或图文视频COZE的工作流是能胜任的。但如果要做复杂的影视级视频还是得用专业的视频生成工具。6.7 本地部署与开源版的现状COZE目前有开源版但功能相比SaaS版有裁剪。我试过在本地部署开源版核心的智能体搭建和工作流功能是有的但一些高级插件和知识库的向量化能力需要自己接。部署过程不算复杂官方提供了Docker镜像但需要自己准备向量数据库和模型推理服务。如果团队有运维能力本地部署能解决数据合规问题但维护成本不低。7. 关于智能体工作流搭建的一些延伸思考7.1 工作流的确定性 vs 智能体的灵活性这是我在多个项目里反复权衡的问题。工作流的好处是确定性每一步都是预设好的不会跑偏。坏处是僵化用户的问题稍微变个说法可能就匹配不上预设的分支。智能体的好处是灵活能处理各种奇怪的问法。坏处是不可控有时候会做出意料之外的动作。我的经验是核心业务流程用工作流保证确定性边缘场景用智能体的自由对话能力兜底。比如制度助手查条款和对比分析走工作流闲聊和引导走智能体的自由对话。这样既保证了关键功能的稳定又不会让用户觉得机器人在生硬地走流程。7.2 提示词工程的边际效应提示词工程在COZE里很重要但它的效果是有上限的。我试过把一个提示词改了几十版前几版效果提升很明显到后面就基本没什么变化了。这时候再继续改提示词不如去优化知识库的分段策略或者调整工作流的节点编排。提示词能解决的是“模型知道该做什么”的问题但解决不了“模型能力不够”的问题。如果某个任务模型本身就不擅长比如复杂的数学计算、精确的日期推理再好的提示词也没用得靠代码节点或插件来补。7.3 多智能体协作的可行性COZE支持在一个工作空间里创建多个智能体但智能体之间的直接调用目前还不算成熟。我试过用工作流来编排多个智能体的调用思路是主智能体接收用户请求通过工作流调用子智能体子智能体返回结果后再由主智能体汇总。实测下来这种模式在简单场景下能跑通但延迟会增加而且子智能体的上下文管理比较麻烦。如果确实需要多智能体协作更稳妥的做法是用一个主智能体加多个工作流而不是多个智能体互相调用。工作流之间的数据传递比智能体之间的通信更可控。7.4 智能体的评估与迭代智能体上线不是终点而是起点。我通常会建立一套评估指标回答准确率、工作流调用成功率、平均响应时间、用户追问率。每周看一次这些指标的变化针对性地做优化。回答准确率靠人工抽检每周抽50条对话看有多少条是正确回答了用户问题的。工作流调用成功率从日志里直接统计。平均响应时间也是日志里看。用户追问率是一个很有意思的指标如果用户问了一个问题之后马上追问“你没理解我的意思”或者“我问的是另一个”说明智能体的意图识别有问题。这套评估机制让我在迭代的时候有数据支撑而不是凭感觉改。很多时候我觉得某个提示词改得很好但数据上准确率反而下降了。数据不会骗人。7.5 关于AI智能体取代工作的真实感受我在多个行业里见过智能体落地的案例。说实话目前阶段的智能体更多是“辅助”而不是“取代”。它能处理的是标准化程度高、重复性强的任务比如查制度、筛简历、回答常见问题。但涉及到需要判断力、需要跨部门协调、需要处理例外情况的工作智能体还差得远。我自己的做法是把智能体当成一个“永远不会累的实习生”。它能帮我处理80%的常规问题剩下的20%复杂问题由人来处理。这样人的精力可以集中在真正需要创造力和判断力的地方。这个定位比“取代”更现实也更容易在组织里推动落地。7.6 后续可以扩展的方向制度助手这个项目跑通之后我陆续扩展了几个方向。一个是把智能体接入企业微信员工直接在企微里就能问制度问题。另一个是加了主动推送功能当公司发布新制度时智能体自动推送给相关部门的员工。还有一个方向是做了制度考试的自动出题和批改用工作流从制度库里抽条款生成选择题员工答完之后自动评分。这些扩展都不是一开始就规划好的而是在使用过程中发现需求之后逐步加的。我的体会是不要试图一次性设计一个完美的智能体先让它跑起来然后在真实使用中迭代。用户会告诉你他们需要什么这比闭门造车靠谱得多。7.7 给刚接触COZE的朋友的几条建议如果你刚开始用COZE我的建议是第一周不要看太多教程直接上手搭一个最简单的智能体哪怕只是“你问我答”也行。第二周开始尝试加知识库感受一下检索的效果。第三周再碰工作流从两个节点的简单流程开始。不要一上来就搞复杂的工作流那样很容易被各种报错劝退。还有一个建议是加入COZE的开发者社区里面有很多人分享自己的工作流模板和提示词。我很多技巧都是从社区里学来的比如用代码节点做JSON解析、用条件判断做多分支路由。站在别人的肩膀上能省很多时间。最后说一个我自己的习惯每次搭完一个智能体我都会写一份简短的搭建笔记记录用了哪些节点、提示词的关键约束是什么、踩了哪些坑。这份笔记在下次搭类似智能体的时候非常有用能避免重复踩坑。这个习惯看起来麻烦但长期来看节省的时间远超写笔记的时间。