低代码平台Agent集成实践

写在前面

Agent 的基础形态是对话。但在实际应用中，单轮对话通常不够。用户需要的是一个能读取数据、调用工具、拆分任务、生成结果并接入业务系统的自动化单元。

这篇文章整理的是 Agent 从简单问答走向工程应用时最常见的几类能力：批处理、数据表、知识库、多 Agent、多工作流和 API 集成。它们解决的问题不同，但底层逻辑一致：把大模型放在可控流程中，让模型负责理解、生成和推理，让工具负责确定性执行，让数据表和工作流负责状态管理。

一句话概括

Agent 工程化不是让模型一次性完成所有事情，而是把任务拆成可验证的节点。模型节点解决语义问题，代码节点解决确定性问题，知识库解决外部知识问题，数据表解决状态问题，工作流解决流程编排问题，API 解决系统集成问题。

1. 批处理：把同类任务交给同一个流程

批处理适合处理结构相同、输入不同、输出格式一致的任务。例如把一首诗拆成多个画面，再分别生成绘图提示词和图像。这里的关键不是文生图，而是如何把一个长输入拆成稳定的列表，并让后续节点逐项处理。

一个典型流程可以拆成五步。首先输入完整诗词；随后由 LLM 提取分镜；再由代码节点把自然语言分镜整理成数组；之后批处理节点逐项生成绘图提示词；最后调用文生图插件生成多张图片。

代码节点的作用是把不稳定的自然语言输出转换成稳定的数据结构。这里不建议让后续节点直接读取一段长文本，因为分镜数量、换行和标点都可能变化。

import re

def extract_scenes(scenes_text: str) -> dict:
    pattern = r"场景\d+：([^场景]+)"
    scenes = [
        match.group(1).strip()
        for match in re.finditer(pattern, scenes_text, re.DOTALL)
    ]
    return {
        "scenes": scenes,
        "scene_count": len(scenes)
    }

这个流程的工程重点有三个。

第一，批处理节点的输入应该是数组，而不是未整理的文本。第二，每个批处理单元应只完成一个目标，例如只生成提示词，不同时生成提示词、翻译和解释。第三，批处理结果要保留顺序，方便把输入场景和输出图片一一对应。

批处理不适合强依赖上下文递进的任务。如果第 3 个结果必须依赖第 2 个结果的判断，就应改用串行工作流或状态机。

2. 数据表与知识库：让 Agent 具备状态和外部知识

智能投顾是一个更接近业务系统的案例。用户提交风险测评信息后，系统需要保存客户画像，再结合证券产品知识库生成产品推荐。这个场景不能只靠聊天上下文完成，因为客户信息需要持久化，产品信息也需要可检索和可更新。

这个流程有两个数据源。一个是结构化数据表，用来保存客户风险测评；另一个是产品知识库，用来检索产品说明、风险等级和适配条件。

投顾推荐的核心不是让模型猜用户适合什么，而是把推荐变成一个受约束的匹配问题。客户风险偏好先映射到风险等级，再检索候选产品，最后由模型生成解释。

输入：客户年龄、投资经验、风险偏好、产品知识片段
处理：
1. 判断客户风险等级
2. 排除风险等级高于客户承受能力的产品
3. 对候选产品按收益特征、流动性、投资期限排序
4. 生成推荐理由和风险提示
输出：推荐产品、适配原因、风险说明

这类场景需要特别注意两点。第一，风险等级、产品范围、合规提示应尽量由规则或知识库提供，不要完全交给模型自由判断。第二，模型输出应包含依据，至少说明推荐来自哪些客户字段和产品属性，否则结果无法审阅。

示例：智能投顾推荐

假设用户在页面中提交如下信息。

提交后，工作流先把测评结果写入 client_risk_assessment 数据表。这个步骤的意义是保存状态，后续再次咨询时不必重新询问客户基础信息。随后，工作流检索证券产品知识库，例如产品名称、风险等级、投资期限、收益特征和赎回规则。模型只在这些候选片段中生成推荐，不应凭空补充产品。

这个例子说明，投顾类 Agent 的重点不是让模型表现得像理财顾问，而是把“客户画像-产品检索-风险约束-解释生成”串成一个可检查流程。只要其中任一环节缺少结构化约束，推荐结果就容易变成看似合理但无法审计的文本。

3. 客户分层：结构化数据驱动营销策略

客户分层营销的目标不是泛泛地生成营销话术，而是根据客户资产规模、交易频率、风险偏好和近期行为，判断客户所处层级，再匹配合适的营销策略。

这里使用三类数据。user_tag 保存客户标签，如资产、风险偏好、客户等级；user_behavior_event 保存近期行为，如登录、浏览广告、查看收益；营销策略表保存不同客户类型对应的触达方式和策略模板。

上图展示了一个分层结果：系统先检索客户画像和行为数据，再生成分层标签，最后给出营销时机、渠道和话术。这个结果的价值在于它不是单纯生成文案，而是把文案绑定到了可解释的分层依据。

这个案例可以抽象为如下流程。

客户 ID
→ 查询客户标签
→ 查询近期行为
→ 判断客户分层
→ 检索营销策略
→ 生成触达建议

在工程实现上，客户分层适合采用“数据查询 + 规则约束 + LLM 生成”的结构。数据查询负责获得事实，规则约束负责决定候选策略，LLM 负责把策略转写成自然语言。这样可以避免模型直接从客户 ID 推断结论。

示例：客户分层营销助手

4. 多 Agent：按职责拆分，而不是按功能堆叠

当一个 Agent 同时承担分流、咨询、投诉处理、数据查询和记录写入时，提示词会迅速变长，工具权限也会变得混乱。多 Agent 更适合职责差异明显的场景，例如智能客服。

这个客服系统可以拆成三个角色。客服总控 Agent 只负责识别意图和分流；理财咨询 Agent 负责产品解释、规则说明和风险提示；投诉处理 Agent 负责查询客户行为、定位问题并记录投诉。

这种拆分的核心是权限隔离。理财咨询 Agent 不需要写入投诉表，投诉处理 Agent 也不应该自由推荐产品。每个 Agent 只拿到完成自身任务所需的知识库、数据表和工具。

多 Agent 不是越多越好。只有当角色边界清晰、工具权限不同、输出目标不同的时候，多 Agent 才有明显收益。若只是把一个长流程拆成多个名字不同的 Agent，但共享同一套提示词和工具，本质上只是增加了复杂度。

示例：智能客服Agent

5. 多工作流：把复杂任务拆成可复用子流程

市场舆情监测是一个典型的多工作流场景。它需要同时处理证券新闻和应用商店评论，再把两类信息汇总成日报。这个任务如果放进一个长工作流，节点会很多，调试困难，也不利于复用。

更合理的做法是拆成三个子流程。证券新闻流程负责抓取和摘要；应用商店评论流程负责评论抓取、情绪分类和词云；日报流程负责整合结果并生成报告。

新闻抓取部分的核心逻辑并不复杂。它从财经新闻接口分页获取新闻列表，再进入详情页解析发布时间和正文，最终返回统一的 data 数组。

def handler(args):
    all_news = []

    for page in range(1, 21):
        news_list = get_news_list(page)

        for news in news_list[:3]:
            title = news.get("title")
            url = news.get("url")
            publish_time, content = get_news_detail(url)

            all_news.append({
                "title": title,
                "publish_time": publish_time,
                "content": content,
                "url": url
            })

    return {"data": all_news}

这个代码片段表达的是数据采集节点的边界：只负责抓取和结构化，不负责摘要、不负责判断情绪，也不负责生成报告。后续分析交给 LLM 节点或专门的分类节点。

日期过滤也应放在确定性节点中完成。新闻发布时间和用户输入日期是明确字段，用代码比较比让模型判断更稳定。

const sameMonthDay =
  now.month === publish.month && now.day === publish.day ? 1 : 0;

return { same_month_day: sameMonthDay };

多工作流的价值在于复用和隔离。证券新闻流程可以单独调试，评论分析流程可以单独替换，日报生成流程可以接入不同数据源。复杂 Agent 不应追求一个巨大流程，而应追求多个边界清楚的小流程。

示例：市场舆情监测日报

这个例子可以设定为证券公司每天收盘后生成一份舆情日报。输入只有一个日期，例如 2025-03-02。系统需要回答三个问题：当天有哪些重要证券新闻，用户在应用商店的反馈集中在哪些问题，是否存在需要运营或产品团队关注的负面信号。

如果把它写成单个工作流，流程会很长：抓新闻、解析正文、过滤日期、摘要、抽关键词、抓评论、判断情绪、生成词云、合并报告。更好的方式是拆成三个子流程。

其中，证券新闻流程只负责生成结构化新闻列表。

{
  "data": [
    {
      "title": "新闻标题",
      "publish_time": "2025-03-02 22:32",
      "content": "新闻正文",
      "url": "新闻链接"
    }
  ]
}

评论分析流程则更适合交给模型做分类和归纳。例如把评论分成“功能问题”“体验问题”“费用问题”“正向反馈”等类别，再统计负面高频词。日报生成流程不再直接处理原始网页和评论，只接收两个子流程的结构化结果。

最终日报可以按如下结构输出。

一、市场新闻概览
提炼当天重要新闻，并说明可能影响的业务方向。

二、用户评论分析
区分正向反馈和负向反馈，列出高频问题。

三、风险信号
指出集中投诉、异常负面词或需要人工复核的信息。

四、处理建议
给出运营、客服或产品侧的后续动作。

多工作流不是为了把流程画得更复杂，而是为了让不同类型任务有独立边界。采集流程可以替换数据源，分析流程可以替换模型，报告流程可以替换模板。这样维护成本更低，也更容易定位错误。

6. API 集成：让 Agent 成为业务系统的一部分

平台里的 Agent 只是应用原型。要进入真实业务系统，需要通过 API 接入网站、后台任务、桌面工具或自动化脚本。

Coze 的客户端调用可以按交互方式分成三类：普通对话、流式对话和带历史记录的对话。普通对话适合短任务；流式对话适合前端实时展示；带历史记录的对话适合业务系统自行维护上下文。

流式响应处理时，应明确只把最终回答内容返回给用户，把工具调用、函数调用和追问等事件作为调试信息或中间状态处理。

for event in stream:
    if event.event == ChatEventType.CONVERSATION_MESSAGE_DELTA:
        msg = event.message
        if msg.type == MessageType.ANSWER:
            yield msg.content

Dify 的 API 调用需要区分应用类型。Chat 应用使用 /chat-messages，Completion 应用使用 /completion-messages，Workflow 使用 /workflows/run。工程上最好显式选择端点，不要依赖自动尝试不同接口，否则线上问题不容易定位。

API 集成的重点不是把请求发出去，而是定义系统边界。业务系统负责用户、权限、页面和任务调度；Agent 负责语义理解、工具调用和内容生成；数据库负责持久化。边界清楚，后续替换模型或平台才不会牵动整个系统。

7. 工程选择

不同 Agent 能力适合不同问题。选择时可以先判断任务是否需要状态、是否需要外部知识、是否需要多角色协作、是否需要接入外部系统。

我的理解是，Agent 开发可以从三个问题开始设计。

第一，哪些事情必须由模型完成。语义理解、摘要、改写、解释和开放式生成适合交给模型。

第二，哪些事情必须由程序完成。字段解析、日期比较、格式转换、数据库写入和权限判断不应交给模型自由发挥。

第三，哪些事情需要被保存。客户画像、投诉记录、推荐结果、日报链接等信息，需要进入数据表或业务数据库，而不是停留在聊天上下文里。

小结

复杂Agent 的核心不是增加更多节点，而是让每个节点承担清楚的职责。批处理解决重复执行，数据表解决状态保存，知识库解决外部知识，多 Agent 解决角色拆分，多工作流解决复杂编排，API 集成解决业务接入。

真正可维护的 Agent 应该像一个小型工程系统：输入可控，流程可拆，数据可查，输出可解释，错误可定位。只有做到这些，Agent 才能从演示走向长期可用。