Agent 学习手记（三）：Agent开发流程

四、Agent 开发通用流程

基于实践，通常会按照3个阶段、10个环节开发一个具备生产机应用、商业化能力的Agent。

①规划阶段。包括定义应用场景、梳理业务流程和痛点、梳理功能定位和开发需求3个环节。

②设计阶段。包括绘制运行流程图、设置大模型及参数、设计提示词、配置技能、设计用户沟通页面5个环节。

③上线阶段。包括测试与调优、发布2个环节。

1. 规划 Agent

规划Agent的阶段如同项目立项的可研分析与评估，需要回答以下问题：

①What。这是一个什么样的Agent？它的使用场景是什么？它的用户是谁？它能做什么？

②Why。为什么要开发这个Agent？它能够解决什么问题？与传统业务流程相比，它的价值是什么？与直接使用大模型对话相比，它的价值是什么？

③How。这个Agent如何实现所定义的功能？

规划Agent是开发Agent的底层思考，用以指导Agent的具体设计。

定义Agent的应用场景

场景，指的是一个特定的空间、时间或情境，包含了某种活动、事件或行为的发生。定义应用场景的主要目的是提高对特定用户、特定生活或工作情境问题的处理能力，提高产品或服务满意度。

Agent是AI技术的场景化应用，天然就带有场景化的属性。因此，在设计Agent之前，有必要对其应用场景进行定义。

定义Agent的应用场景通常包括确定Agent的用户群体、Agent的用途、Agent的价值等要素。

比如，AI 投标助手，是一个检索并生成投标文件的关键信息的 Agent ，其用户群体是企业中负责投标的市场部门、商务部门的员工，或参与投标工作的技术部门的员工。该 Agent 的用途是快速阅读用户上传的招标文件，给用户生成准确、全面、结构化的招标文件的关键信息，并准确回答用户关于招标文件的各种问题。该 Agent 的价值是节省人工阅读长达几十页招标文件的时间成本，并方便招标文件的关键信息在不同人员间准确、全面传递，减少人工检索信息的缺漏和传递的偏差。

可以看出，定义 Agent 的应用场景是对规划 Agent 中" What "的回答。一个高质量的 Agent ，应该有明确且具体的用户群体、有效且精准的用途。更重要的是， Agent 要能够具有独特价值。例如 AI 投标助手的独特价值是相对于传统人工信息检索、传递的低效率、信息衰减而言的，通过长文档理解能力，减少人工阅读和查找招标文件的工作量。

梳理业务流程和分析痛点

要想实现Agent的功能，就需要针对Agent的应用场景进行业务流程分析，系统化梳理业务逻辑，并分析痛点，寻找Agent的独特价值，以确保能够有效地解决实际问题。

还是以AI 投标助手为例，基于其应用场景，可以梳理出如下常规的业务流程：① 购买并获取招标文件；② 把招标文件分发给商务、业务相关人员；③ 标记与解读招标文件的关键信息；④ 制定投标策略；⑤ 分模块制作投标文件；⑥ 审核标书；⑦ 投标。 

对于这样的业务流程，可以识别出两大痛点：

痛点一，信息查找费时费力。要从冗长的招标文件中找到关键信息（如开标时间和地点、投标人资格要求、投标保证金、最高限价、付款条件、投标文件组成、评分规则、合同条款等）需要花费大量的人工时间，并且要足够耐心和仔细。

痛点二，信息在传递时容易丢失。制作一份投标文件，通常需要多方协作完成，例如技术人员负责制定技术方案，商务人员负责提供资质、业绩等信息，报价人员负责测算价格，审核人员对照招标评审要点审核投标文件等。招标文件的关键信息在不同岗位间传递，在这个过程中，很容易出现信息丢失、理解偏差等风险，导致投标文件作废或者得分不佳，影响中标。

通过分析业务流程的环节，我们可以从更细致的颗粒度理解 Agent 应用场景下的业务逻辑，确保设计的 Agent 更贴近真实的业务流程，更好地消除用户痛点，满足用户需求。

梳理 Agent 的功能定位和开发需求

在梳理业务流程和分析痛点的基础上，我们要进一步梳理出 Agent 的功能定位和开发需求，用于指导 Agent 的具体设计。

梳理 Agent 的功能定位和开发需求要围绕 Agent 的能力实现展开，包括 Agent 是否需要通过配置专有知识库增强特定领域的大模型输出能力， Agent 执行的任务是否需要通过工作流分解为多个子任务， Agent 是否需要调用插件获得拓展能力。

例如， AI 投标助手需要把人工阅读投标文件识别关键信息的流程，转变为由 AI 系统协助读取招标文件的流程。

经过梳理，其功能定位和开发需求包括：①配置知识库，掌握招投标专业知识，熟悉各类招投标项目的文件结构、术语、内容、关键信息等。②大模型需要具备长文档理解和输出能力，一份招标文件长达几十页甚至上百页，必须选择合适的大模型和 token 参数（输入和输出的文字长度）。③ Agent 的任务流程较短，不需要使用工作流。④ Agent 需要具备阅读和检索用户上传的文档（通常是 pdf 、 doc 、图片等格式的）的技能，需要配置相关功能插件。④输出的结果要有极高的准确性和全面性，需要防止大模型出现"幻觉"。

2.设计 Agent 

在规划 Agent 后，就可以使用 Agent 开发平台开发 Agent 了。

绘制Agent的运行流程图

Agent 的运行流程图对 Agent 执行任务的节点、节点的类型、节点的逻辑关系、节点的先后次序等进行图形化呈现，作用是让开发者根据 Agent 开发平台的功能模块，从整体做好 Agent 的结构化布局和功能路径规划，确保后续开发 Agent 的效率和 Agent 的可靠性。

 Agent 的运行流程图就像一张设计图，指导整个施工过程。绘制Agent运行流程图有利于快速开发Agent。

设置大模型及参数

大模型是 Agent 的大脑，无工作流模式的 Agent 通常只会使用单一的大模型进行思考和回答，工作流模式的 Agent 则可能会多次使用不同的大模型。

设置大模型主要包括大模型选型、设置大模型的参数两个方面。

大模型选型是根据 Agent 的任务需求和应用场景，选择合适的大模型厂商及具体的模型型号。

不同的大模型在处理不同的任务时会存在性能差异。一些大模型也推出了不同上下文长度的模型产品。例如，扣子的豆包模型分为豆包． Function call 模型32K（指模型一次能够处理32,000 token 的文。 token 是文本中最小的语义单元，一个 token 通常等于1~1.8个汉字）和豆包角色扮演模型32K, Kimi 模型分为 Kimi (8K)、 Kimi (32K)、 Kimi (128K)。

要想快速了解大模型的回答效果，可以使用扣子的模型广场功能，进行模型 PK ，以便选用合适的大模型。

最大回复长度则要根据输入模型的文本长度和模型输出的文本长度来判断，8K、32K模型可以满足一般的问答对话任务，但对于长文档的理解和输出任务，如阅读报告、撰写小说等，则需要选择32K、128K等处理长上下文的模型。

设置大模型的参数一般包括生成多样性、输入及输出设置。

生成多样性是非常重要的大文件模型参数，它定义大模型的回复是更精确、更稳定，还是更灵活、更有创意。通常而言，专业问答类、特定领域检索类的 Agent ，要求大模型回答得更精确、更稳定；聊天类、文案创作类 Agent ，要求大模型回答得更灵活、更有创意。

输入设置主要是对上下文对话轮数的设置。开发者需要合理设置大模型的最大回复长度，特别是对有长文本输出需求的 Agent ，如创作长文档、撰写报告类的 Agent ，需要预测文本长度。

随着 Agent 开发平台开始收费，选择大模型需要考虑经济性问题。合理地设置这些参数，既能确保大模型的效果，也能减少不必要的token消耗。

设计提示词

提示词是 Agent 调用大模型执行任务的指令，是 Agent 规划、思考能力的体现。在开发 Agent 时，设计提示词是很重要的环节，扣子称之为人设与回复逻辑。

单 Agent 模式下的提示词设计和工作流模式下的提示词设计有所不同。

在单 Agent 模式下，通常只有一个提示词， Agent 要靠这个提示词来调用大模型、各类插件、知识库、数据库等功能模块，并按照预定义的格式输出结果。单 Agent 模式下的提示词，就像一个系统规划师。因此，撰写单 Agent 模式下的提示词一般会比撰写工作流模式下的提示词更复杂，难度更大，要求更高。

在工作流模式下，只有大模型节点才需要提示词。提示词的功能是调用大模型执行所在节点的任务。与单 Agent 模式下的提示词指挥全局有所不同，工作流模式下的提示词只在其所在的节点起作用，不影响其他节点运行。如果一个工作流中有多个大模型，就需要配置多个提示词，每个提示词都只会匹配各自节点的大模型。

无论在哪种模式下，设计提示词的方法和技巧都是通用的。不同场景的 Agent ，在提示词结构上有所差异，如角色扮演类 Agent 的提示词包括人设／角色、性格特点、语言特点、行为方式、限制／注意事项，工具类 Agent 的提示词包括人设／角色、技能、知识、限制／注意事项，图像创作类 Agent 的提示词包括人设／角色、详细描述、风格、色彩、情感表达、技能、限制／注意事项。

配置 Agent 技能

配置 Agent 技能是让 Agent 掌握使用各类工具的能力，从而实现 Agent 的能力扩展。包括：配置插件／ API 、工作流、知识库、数据库、变量、卡片等。

设计用户沟通页面

前面环节已经完成了Agent核心功能开发，设计用户沟通页面是为了便于用户快速理解、正确使用Agent。包括：设计开场白、引导 / 预置问题、快捷指令、背景图片、语音 / 数字人等。用户沟通页面不影响Agent的能力输出和功能发挥。

3. 上线 Agent

测试与调优

在上线 Agent 前，通常需要多次测试与调优。

对话调优是所有 Agent 开发平台都具备的功能，即在发布 Agent 前，通过用户对话测试 Agent 的回答效果，判断 Agent 功能配置的有效性。

但是对于复杂工作流的 Agent ，仅通过对话输入和 Agent 结果输出，很难识别和发现 Agent 内部运行过程中存在问题的环节，修正难度较大。所以，扣子平台提供了调试台功能。调试详情包括：耗时、调用树 / 火焰图、节点详情、输入、输出等信息。

发布

在测试和调优后，就进入发布环节。

Agent 一般有3种发布和使用方式：一是发布到 Agent 开发平台的智能体商店中使用；二是发布到微信、抖音、飞书等第三方社交或工具平台中使用；三是通过 API 发布，这样可以通过 API 调用把 Agent 集成到其他产品或服务中使用。

第一种和第二种方式操作起来非常简单，单击 Agent 开发平台的"发布"按钮，勾选相关的发布平台（也称为发布渠道），经过审核后就可以上线使用了。

对于第三种方式，在发布完成后，还需要根据自身需要完成 API 调用配置。

五、开发Agent的策略

1. 懂场景和懂业务，比懂AI技术更重要

Agent的本质是基于特定场景结合AI技术再造业务流程。AI技术只有与业务紧密结合，才能真正发挥作用。

随着人机交互页面的简化，精通业务的人可以零代码规划Agent，制作Demo，甚至完成全流程的Agent开发。

一个优秀的Agent开发者，首先应该是一名业务专家，其次才是掌握Agent开发工具使用方法的开发者。

Agent开发者一定要具有业务专家的思维，提高业务理解能力和设计能力，从应用场景和业务分析视角规划和设计Agent，从而提高Agent解决问题的效果。

2. 使用工具拓展能力，是Agent具有价值的关键

Agent = 大模型 ×（规划+记忆+使用工具+行动）。要想评估一个Agent的功能是否强大，可以看它在这些方面的配置情况。

如果一个角色聊天类Agent没有配置知识库，没有使用插件，也没有工作流、数据库、记忆等，仅仅设计了提示词，那么它的能力和大模型生成不会有很大差别。

3. 坚持小而美，聚焦特定的应用场景和功能

Agent 是针对特定的应用场景的轻应用，可以和 RPA（机器人流程自动化）结合。 Agent 可以通过 API 接入日常软件，也可以和其他 Agent 协作。因此， Agent 开发者应该坚持小而美的理念，从最小颗粒度的应用场景和功能入手，定义 Agent 的应用场景，设计 Agent 。

应用场景越具体，用户越聚焦， Agent 的实现路径就越明确，其落地性就越强、价值就越大。反之，如果我们用开发软件的思维，划定了复杂而广泛的应用场景和功能，那么很可能导致在技术上无法实现 Agent ，或者其稳定性不佳。

4. 把Agent当成助手，而不是一个完全托管的解决方案

无论是 AI 技术，还是 Agent 的发展，目前都处于探索阶段。我们离 AGI（通用人工智能）还有一段距离。 Agent 在智能化、自动化、多功能化、性能稳定性等方面都需要提升。

作为 Agent 开发者，我们必须清楚地认识到这一点，对 Agent 过于理想化的想法，可能会给 Agent 的开发，或者 Agent 的应用推广带来困难和风险。另外， Agent 作为 AI 工具，它的设计初衷是辅助人类，提高效率，而不是取代人类的决策。

因此，在使用 Agent 时，我们应该将其视为一个助手，而不是一个完全托管的解决方案。用户需要对 Agent 输出的内容进行判断、筛选、加工，而不是盲目地接受和直接使用。