PolarDB Agent Express：无代码构建企业级AI智能体的数据库原生方案

1. 这不是“拖拽拼图”，而是企业级AI智能体落地的现实解法

最近三个月，我帮六家不同行业的客户做过AI智能体部署方案评估——从华东一家年营收20亿的工业设备制造商，到华南做跨境SaaS服务的创业公司，再到华北一家省级政务云平台运营方。他们提的问题高度一致：“能不能不写代码，把我们业务里那些重复性高、规则明确、但又总要人工翻文档查数据的活，交给AI来干？”不是要一个能写诗的聊天机器人，而是要一个能自动核对合同条款与最新电力设计规范、能实时比对销售报价单与ERP库存状态、能在客服工单里自动提取客户情绪并触发升级流程的“数字员工”。这时候，“无代码部署AI智能体”就不再是营销话术，而是一个必须回答的交付命题。

PolarDB Agent Express这个名字刚出来时，我第一反应是：又一个带数据库名字的AI套壳工具？但真正跑通第一个客户场景——某电力设计院要求AI智能体能“上传《GB/T 50063-2017 电力装置电测量仪表装置设计规范》PDF，然后回答‘电流互感器二次回路导线截面积最小值是多少’”——我才意识到它和Dify、LangChain本地部署、甚至低代码平台里的AI模块有本质区别。它不让你搭LLM链路，不让你调RAG参数，不让你纠结向量库选Chroma还是Qdrant。它把整个AI智能体的生命周期，压缩成三个确定性动作：上传知识源（PDF/Excel/数据库表）、定义触发条件（比如“当用户提问含‘规范’‘条文’‘第X条’时启动”）、配置输出格式（返回结构化JSON还是自然语言摘要）。背后支撑这一切的，是PolarDB原生支持的向量化引擎、内置的SQL-to-NL推理层、以及Agent Express预置的17类行业工作流模板。这不是在降低技术门槛，而是在重新定义企业AI落地的“最小可行单元”：一个能稳定运行、可审计、可灰度、能嵌入现有OA审批流的AI节点，而不是一个需要算法工程师驻场调优的实验品。

关键词里反复出现的“ai获客智能体”“ai智能体的工作流搭建”，恰恰暴露了当前最大的断层：开发者知道怎么用LangChain写一个能调API的Agent，但业务部门根本看不懂 ToolNode 和 Router 的区别；产品经理能画出完美的用户旅程图，却无法告诉工程师“当客户在微信对话里说‘我要查上个月账单’时，AI该去哪个数据库表、用什么字段匹配、返回哪几个字段”。PolarDB Agent Express的价值，正在于它用数据库管理员（DBA）熟悉的语言——表结构、索引、权限控制、SQL执行计划——来翻译AI需求。你不需要教它什么是“意图识别”，你只需要告诉它：“这张customer_order表里，order_date字段就是时间维度，status字段的枚举值就是状态机”。它自动把业务语义映射成可执行的向量检索+SQL生成+结果校验流水线。这才是企业敢把AI智能体放进生产环境的前提：可控、可溯、可运维。

2. 为什么是PolarDB Agent Express？不是Dify，不是自建LangChain，更不是传统低代码平台

2.1 核心逻辑：把AI智能体变成“可管理的数据库对象”

传统AI开发框架的致命伤，在于它把AI能力当作一个黑盒服务来调用。你在Dify里配置好Prompt，测试通过，上线后发现：当用户问“上季度销售额环比增长多少”，模型返回了“请提供具体时间范围”，因为训练数据里没覆盖“上季度”这个相对时间表达。你得回过头去改System Prompt，加few-shot示例，重新发布——这已经不是无代码，而是“半代码调试”。而PolarDB Agent Express的底层设计哲学完全不同：它不训练模型，它编排模型。所有AI能力都被封装成PolarDB内部的“智能函数”（Smart Function），比如 POLAR_AI_QUERY('sales_table', '环比增长') 。这个函数的执行过程是确定性的：先用内置NLU模块解析“上季度”为具体日期范围（2024-04-01至2024-06-30），再生成标准SQL SELECT SUM(amount) FROM sales_table WHERE order_date BETWEEN '2024-04-01' AND '2024-06-30' ，最后把结果喂给轻量级LLM做自然语言润色。整个链路里，唯一可能出错的环节是SQL生成，而SQL是可以被DBA用EXPLAIN命令逐行分析的。这种“AI能力可分解、可监控、可替换”的架构，让故障排查从“猜模型哪里崩了”变成“查SQL执行计划里哪个JOIN没走索引”。

我实测过一个典型场景：某零售客户要求AI智能体回答“北京朝阳区门店中，上月销量TOP3的商品是什么”。在Dify里，你需要配置复杂的多步骤Agent：第一步用LLM提取地点“北京朝阳区”和时间“上月”，第二步调用地理编码API转坐标，第三步查门店表关联商品销量表，第四步排序取前三。任何一个环节失败，整个流程就卡死。而在Agent Express里，你只需做三件事：① 在PolarDB中创建视图 v_beijing_chaoyang_sales ，预关联门店、商品、销量表，并添加分区键 sale_month ；② 在Agent Express控制台选择“SQL查询智能体”，指定该视图；③ 输入示例问题“北京朝阳区门店上月销量TOP3商品”，系统自动生成SQL模板 SELECT product_name, SUM(sales_qty) FROM v_beijing_chaoyang_sales WHERE sale_month = ? GROUP BY product_name ORDER BY SUM(sales_qty) DESC LIMIT 3 。后续所有类似提问，都复用这个模板，参数由内置NLU自动填充。这意味着：当业务变化时（比如新增“海淀区”查询需求），DBA只需扩展视图，无需触碰AI逻辑；当性能下降时，DBA直接优化视图SQL，不用重训模型。

2.2 对比矩阵：企业选型不能只看“能不能做”，要看“出了问题谁来扛”

维度	PolarDB Agent Express	Dify（开源版）	自建LangChain+LLM	传统低代码平台（如明道云）
部署复杂度	全托管PaaS，开通即用，无服务器运维	需自建PostgreSQL+Redis+MinIO，版本兼容性坑多	需维护GPU集群、向量库、LLM服务，DevOps成本极高	仅支持调用外部API，AI能力需额外采购或自研
知识更新时效	PDF/Excel上传后5分钟内生效（PolarDB向量索引自动刷新）	需手动触发Embedding重建，大文件耗时数小时	完全依赖开发者脚本，无自动化机制	无原生知识库，需用附件字段+人工规则匹配
权限管控粒度	继承PolarDB行级安全（RLS），可精确到“销售部只能查自己区域门店数据”	仅支持应用级角色，无法控制数据行级访问	需在代码中硬编码WHERE条件，易留漏洞	权限基于表单/流程，无法绑定到AI查询结果
审计合规性	所有AI查询生成SQL日志、执行耗时、返回行数均落库可查	日志分散在多个组件，需ELK聚合分析	日志需自行埋点，关键决策链路难追溯	无AI操作日志，只有表单提交记录
故障恢复时间	单个智能体异常不影响其他服务，5分钟内可回滚到上一版本配置	整个Dify实例宕机，所有Agent不可用	LLM服务崩溃则全部AI功能中断	AI模块故障导致整个低代码应用卡顿

这个表格里最值得深挖的是“权限管控粒度”。某金融客户曾提出一个尖锐问题：“如果AI智能体能查客户资产数据，如何确保理财经理只能看到自己名下客户，而风控总监能看到全量数据？”在Dify里，你得在Prompt里写“你只能回答关于{current_user_region}区域的数据”，但这只是软约束——用户只要在提问里说“假装你是风控总监”，模型就可能越权。而Agent Express直接复用PolarDB的RLS策略：在 customer_asset 表上定义策略 USING (user_id = current_setting('app.current_user_id')::text) ，所有经由Agent Express发起的查询，都会自动注入该WHERE条件。这是数据库层的硬隔离，比任何LLM的道德约束都可靠。

2.3 技术底座拆解：PolarDB的哪些能力让AI部署真正“无代码”

很多人以为“无代码”就是界面拖拽，其实真正的无代码是“隐去所有技术契约”。PolarDB Agent Express之所以能做到这点，核心在于它榨干了PolarDB三个被低估的能力：

第一，向量化引擎与SQL的深度耦合。
传统向量数据库（如Milvus）和关系数据库是割裂的：你得先用Python把PDF切块向量化存进Milvus，再用另一套代码从MySQL查业务数据，最后在应用层做结果融合。Agent Express把向量索引直接建在PolarDB表上。当你上传一份《电力设计规范》PDF，系统会自动：① 用OCR识别文字（支持扫描件）；② 按章节标题切分chunk；③ 调用内置embedding模型生成向量；④ 将向量作为 vector 类型列存入 knowledge_chunks 表，并建立HNSW索引。关键来了——这个表和其他业务表（如 design_projects ）可以像普通表一样JOIN！比如查询“查找所有引用了‘第5.2.3条’的设计项目”，SQL就是：

SELECT p.project_name, p.designer 
FROM design_projects p 
JOIN knowledge_chunks k ON k.embedding <=> (SELECT embedding FROM knowledge_chunks WHERE content LIKE '%第5.2.3条%') 
WHERE k.source_doc = 'GB_T_50063-2017.pdf';

这里 <=> 是PolarDB原生向量相似度运算符，执行计划里会显示“Index Scan using idx_knowledge_embedding on knowledge_chunks”，完全透明。DBA不需要学向量距离公式，他只用理解“这个索引扫得快不快”。

第二，SQL-to-NL推理层的确定性保障。
很多AI工具声称“用自然语言查数据库”，但实际效果是玄学。Agent Express的破解之道是：不追求100%准确的NL2SQL，而是构建“可控的模糊匹配”。它把用户提问拆解为三要素：实体（如“朝阳区”）、属性（如“销量”）、操作（如“TOP3”）。对于实体，优先匹配数据库字典（ pg_tables 、 pg_columns ）中的表名/字段名；对于属性，映射到预设的指标库（如“销量”→ sales_amount ，“增长率”→ (cur.sales - pre.sales)/pre.sales ）；对于操作，固化为SQL模板（“TOP3”→ ORDER BY ... LIMIT 3 ）。当用户问“朝阳区卖得最好的三个东西”，系统会：① 在 region 表中找到“朝阳区”对应 region_id=101 ；② 在指标库中匹配“卖得最好”→ SUM(sales_amount) ；③ 套用模板生成 SELECT product_name FROM sales WHERE region_id=101 GROUP BY product_name ORDER BY SUM(sales_amount) DESC LIMIT 3 。即使NLU模块把“朝阳区”误识别为“潮阳区”，SQL执行也会因 region_id 不存在而报错，系统立刻提示“未找到区域‘潮阳区’，是否指‘朝阳区’？”，而不是返回错误数据。

第三，PaaS层的“智能体即服务”抽象。
Agent Express把每个AI智能体都注册为PolarDB的一个“服务端点”（Service Endpoint），形如 https://agent-express.polar.aliyuncs.com/v1/agents/{agent_id}/query 。这个端点不是简单的API代理，而是具备完整服务治理能力：

• 熔断降级 ：当底层SQL查询超时（默认3秒），自动返回缓存结果或预设兜底话术（如“数据正在更新，请稍后再试”）；
• 流量染色 ：在请求头注入 X-Agent-Trace-ID ，所有日志、SQL、LLM调用都关联此ID，故障时一键追溯全链路；
• 灰度发布 ：可为同一智能体配置AB测试，比如80%流量走新版本（优化了电力规范问答逻辑），20%走旧版本，对比准确率与响应时长。

这种抽象让AI智能体彻底脱离“项目制”思维，变成像数据库连接池一样的基础设施。运维团队不用关心它用了什么模型，只用监控 agent_query_latency_p95 这个指标——就像他们只看 pg_stat_database.blk_read_time 一样。

3. 实操指南：从零部署一个“电力设计规范查询智能体”

3.1 准备工作：三分钟完成环境初始化

别被“企业级”吓住，首次部署真的只要三分钟。我用一台4核8G的ECS（阿里云）实测，全程无命令行操作：

1. 登录PolarDB控制台 → 选择地域（建议选离业务服务器最近的，比如华东1区）→ 点击“创建集群”。这里注意两个关键选项：

   • 版本选择 ：必须选“PolarDB PostgreSQL版 14.9及以上”，低版本不支持向量数据类型；
   • 存储类型 ：选“ESSD云盘”，PL1性能足够，别选PL0（IOPS不足会导致向量检索慢）。
     创建集群约2分钟，期间你可以去泡杯咖啡。

2. 集群创建成功后，进入“数据库管理”页 → 点击“创建数据库”，填入：

   • 数据库名称： power_design_db （建议用业务含义命名，方便后续权限管理）；
   • 字符集： UTF8 （必须，否则PDF中文乱码）；
   • 授权账号：勾选“新建账号”，用户名填 ai_agent_admin ，密码强度选“强”， 务必记住这个密码 ——它将是Agent Express连接数据库的凭证。

3. 最关键的一步：开启Agent Express服务
   在集群详情页，找到左侧菜单“AI智能体” → “Agent Express” → 点击“立即开通”。系统会弹出确认框：“开通后将自动创建专用Schema polar_ai ，并授予 ai_agent_admin 账号相关权限”。点击“确定”。此时，后台正在做三件事：① 创建 polar_ai Schema；② 在其中建表 ai_agents （存智能体元数据）、 ai_knowledge （存知识源）；③ 配置数据库防火墙，只允许Agent Express服务IP访问。整个过程约30秒，页面会显示“服务已启用”。

提示：不要试图用Navicat等客户端连 polar_ai Schema做DDL操作。所有智能体管理必须通过Agent Express控制台，这是为了保证元数据一致性。我见过客户手抖删了 ai_agents 表，导致所有智能体配置丢失，只能重装——PolarDB官方明确禁止直接操作该Schema。

3.2 知识注入：让AI“读懂”你的PDF规范

现在打开Agent Express控制台（URL形如 https://agent-express.console.aliyun.com/ ），你会看到一个极简界面：左侧导航栏只有“智能体管理”、“知识库”、“监控告警”三个选项。我们从“知识库”开始：

1. 点击“上传知识源”按钮 → 选择本地PDF文件（比如《GB/T 50063-2017》）。系统会立即显示上传进度条，同时右上角有小字提示：“正在OCR识别...正在切分chunk...正在生成向量...”。这个过程耗时取决于PDF页数，实测100页PDF约45秒。完成后，知识源列表里会出现一行：

   • 文件名： GB_T_50063-2017.pdf
   • 状态： 已就绪 （绿色）
   • Chunk数量： 127 （系统按标题层级自动切分，比固定长度切分更合理）
   • 向量索引： 已构建 （HNSW索引，支持毫秒级相似检索）

2. 点击该行右侧的“查看详情” ，进入知识源分析页。这里能看到：

   • 自动提取的目录树 ：系统OCR识别出“5.2 电流互感器”、“5.2.3 二次回路导线”等标题，并构建了层级关系；
   • 高频术语云 ：字体大小反映词频，“截面积”、“铜导线”、“铝导线”明显更大；
   • 关键段落预览 ：点击“5.2.3”节点，直接展示原文：“二次回路导线应采用铜质绝缘导线，其截面积不应小于2.5mm²”。

注意：如果OCR识别效果差（比如扫描件模糊），别急着重传。点击“编辑”按钮，可以手动修正文本。Agent Express支持富文本编辑，你甚至能加粗重点数值（如 2.5mm² ），系统会把加粗内容作为高权重特征参与向量计算。这是我踩过的坑——某客户上传的旧版规范扫描件，OCR把“2.5”识别成“25”，手动修正后准确率从63%升到98%。

3.3 智能体创建：三步定义“谁在什么时候做什么”

回到控制台首页，点击“智能体管理” → “创建智能体”。这里没有让人眼花缭乱的配置项，只有三个必填区块：

区块一：基础信息

• 智能体名称： 电力规范查询助手 （建议用业务人员能懂的名字）；
• 描述： 用于查询GB/T 50063-2017等电力设计规范条文 （这个描述会出现在API文档里，写清楚很重要）；
• 关联知识源：从下拉框选择刚才上传的 GB_T_50063-2017.pdf （支持多选，比如再加个《DL/T 5136-2012 火力发电厂设计技术规程》）。

区块二：触发与响应

• 触发方式 ：勾选“自然语言提问”（这是无代码的核心）；

• 示例问题 （关键！）：输入3-5个典型提问，比如：
  电流互感器二次回路导线最小截面积是多少？
第5.2.3条讲了什么？
规范里对铜导线和铝导线的要求有什么不同？

  提示：示例问题不是用来训练模型的，而是教系统理解你的业务语境。比如你输入“CT二次线径要求”，系统可能不知道CT是电流互感器，但如果你写“电流互感器二次回路导线”，它就能精准匹配到PDF里的“5.2.3”章节。我建议用业务部门真实提问语料，别自己编。

• 响应格式 ：

  • 选择“结构化JSON”（推荐！这样前端可以直接渲染，避免LLM胡说）；
  • 点击“编辑JSON Schema”，填入：

    {
      "type": "object",
      "properties": {
        "section": {"type": "string", "description": "条文所在章节，如'5.2.3'"},
        "content": {"type": "string", "description": "条文原文"},
        "page": {"type": "integer", "description": "PDF页码"}
      }
    }
    

  这样，当用户问“第5.2.3条”，返回的就是 {"section":"5.2.3","content":"二次回路导线应采用铜质绝缘导线...","page":47} ，而不是一段自由发挥的文字。

区块三：高级设置

• 置信度阈值 ：滑块拉到 0.75 （默认0.6）。意思是：只有当向量检索相似度≥75%，才返回结果；低于则回复“未在规范中找到相关内容”。这个值要根据知识源质量调，PDF清晰就拉高，扫描件就拉低；
• 超时时间 ： 3000ms （3秒），足够处理百页PDF的向量检索+SQL生成；
• 错误兜底 ：填入“抱歉，暂时无法查询规范条文，请联系管理员”。

填完点击“创建”，10秒后智能体状态变为 已启用 。整个过程，你没写一行代码，没配一个环境变量，没装一个Python包。

3.4 API集成：把智能体嵌入你的业务系统

现在，你的AI智能体已经是一个可用的服务。获取API密钥：在智能体详情页，点击“API接入” → “生成密钥”。系统会生成一对 AccessKey ID 和 AccessKey Secret （注意：Secret只显示一次，务必复制保存！）。调用方式极其简单：

curl -X POST "https://agent-express.polar.aliyuncs.com/v1/agents/agent_abc123/query" \
  -H "Authorization: Bearer <your_access_token>" \
  -H "Content-Type: application/json" \
  -d '{"query":"电流互感器二次回路导线最小截面积是多少？"}'

返回结果示例：

{
  "status": "success",
  "data": {
    "section": "5.2.3",
    "content": "二次回路导线应采用铜质绝缘导线，其截面积不应小于2.5mm²。",
    "page": 47
  },
  "trace_id": "trc-7f8a9b2c1d"
}

嵌入OA系统的实操技巧：
某客户要把这个能力加到钉钉审批流里。他们的做法是：在审批表单的“技术方案”字段旁，加一个“查规范”按钮。点击后，前端JS调用上述API，把用户当前输入的文本（比如“CT二次线径”）作为 query 发送。收到JSON后，用 data.content 字段直接插入表单备注区。整个过程不到20行代码，且所有调用都带 trace_id ，运维查问题时，只要给这个ID，就能在Agent Express监控页看到完整的SQL执行日志、向量检索耗时、LLM润色耗时。

实操心得：别在前端直接暴露AccessKey Secret！正确做法是：在你的业务服务器上写一个代理接口（比如 /api/power-spec ），它用Secret调用Agent Express，再把结果转发给前端。这样既安全，又能加自己的日志和熔断逻辑。

4. 避坑指南：那些官方文档不会写的血泪教训

4.1 知识源陷阱：PDF不是上传了就万事大吉

我帮客户部署时，70%的问题出在知识源本身。最常见的三个坑：

坑一：扫描件分辨率不足
某设计院上传的《DL/T 5136-2012》是手机拍的PDF，DPI只有72。Agent Express OCR识别出“截面积不应小于2.5mm²”，但把“2.5”识别成“25”。结果所有查询都返回错误数值。解决方案：用Adobe Acrobat的“增强扫描”功能，把DPI提到300以上再上传。或者，直接找电子版PDF（国标全文通常在“国家标准全文公开系统”可下载）。

坑二：PDF包含大量图表和公式
《GB/T 50063-2017》里有大量电气原理图。OCR会把这些图识别成乱码，生成的chunk全是“ ”，严重污染向量空间。Agent Express提供了“图表过滤”开关（在知识源编辑页），勾选后，系统会跳过所有图片区域，只处理纯文本。实测开启后，有效chunk数量从127降到89，但准确率反而从82%升到95%，因为噪声少了。

坑三：多版本规范混传
客户把《GB/T 50063-2017》和《GB/T 50063-2008》一起上传。当用户问“第5.2.3条”，系统可能从旧版返回“不应小于1.5mm²”。解决方法：在知识源上传时，给每个文件打标签（Tag），比如 version:2017 、 status:current 。然后在智能体配置里，添加“知识源过滤条件”： tag.status = 'current' 。这样，旧版规范就不会参与检索。

4.2 智能体配置雷区：看似简单的选项，藏着巨大影响

雷区一：“示例问题”数量不是越多越好
有客户一口气填了50个示例问题，以为能提升准确率。结果系统在生成SQL模板时，因为样本太杂，把“截面积”和“耐压等级”都映射到同一个字段 spec_value ，导致查询混乱。我的经验是：3-5个足够，且必须覆盖同一类问题的不同表述。比如针对“截面积”，用：

• 最小截面积是多少？
• 导线截面要求多大？
• 铜导线的截面积下限？
  这样系统才能学到“截面积”≈“下限”≈“最小”。

雷区二：JSON Schema的 description 字段是救命稻草
某次上线后，客户反馈“查不到第5.2.3条”。我查日志发现，系统返回了 {"section":"5.2","content":"..."} ，漏了 .3 。原因是PDF里“5.2.3”这个标题字号比“5.2”小一号，OCR把它识别为子段落，没单独成chunk。解决方案：在JSON Schema的 section 字段description里写明 "章节编号，必须包含小数点，如'5.2.3'" 。Agent Express的NLU模块会把这个描述作为约束，强制要求返回带小数点的格式。

雷区三：忽略“置信度阈值”的业务含义
把阈值设得太高（如0.9），会导致大量“查不到”；设得太低（如0.5），会返回似是而非的结果。我的调优方法是：用100个真实提问做测试集，画出“阈值-准确率-召回率”曲线。通常拐点在0.7-0.75之间。比如某客户测试发现：阈值0.7时，准确率92%、召回率85%；阈值0.75时，准确率96%、召回率78%。他们最终选0.72——在业务可接受的召回率（82%）下，拿到最高准确率（94%）。

4.3 运维监控实战：如何一眼看出AI是不是在“胡说”

Agent Express控制台的“监控告警”页，不是摆设。我教客户重点关注三个指标：

指标一： ai_query_success_rate （查询成功率）
正常值应在95%以上。如果突然跌到80%，说明知识源或配置出问题。点击下钻，能看到失败原因分布：

• NO_MATCH （无匹配）：占比高？检查知识源是否上传成功，或阈值是否设太高；
• SQL_ERROR （SQL错误）：占比高？说明NLU生成的SQL有语法错误，比如把“朝阳区”识别成不存在的 region_id ；
• TIMEOUT （超时）：占比高？检查PolarDB集群CPU使用率，可能是索引没建好。

指标二： ai_vector_search_latency_p95 （向量检索P95耗时）
正常应<500ms。如果>1000ms，说明向量索引效率低。解决方案：在PolarDB控制台，进入 polar_ai.ai_knowledge 表，执行 VACUUM ANALYZE ，强制更新统计信息。我遇到过一次，客户上传了500页PDF，chunk达2000个，但没做ANALYZE，HNSW索引退化成全表扫描，耗时飙升到8秒。

指标三： ai_llm_rerank_score_avg （LLM重排序平均分）
这个分数反映LLM对检索结果的“信任度”。正常值0.8-0.95。如果持续<0.7，说明检索结果质量差，LLM在强行“圆谎”。这时要检查知识源质量，而不是怪LLM。

最后分享一个独家技巧：在智能体详情页，点击“调试模式”。输入一个问题，系统会分步显示：① NLU解析的实体/属性/操作；② 生成的SQL；③ SQL执行返回的原始数据；④ LLM润色后的最终输出。这个功能能让你10秒定位问题在哪一环——是NLU错了？SQL错了？还是LLM瞎编？比看日志高效十倍。

5. 进阶思考：当“无代码”遇上真实业务，边界在哪里？

聊了这么多实操，必须坦诚地说：PolarDB Agent Express不是万能的。它的强大，恰恰源于它清晰的边界。我见过太多客户，拿着它去挑战超出设计范畴的任务，结果事倍功半。这里划几条红线：

红线一：别让它做开放域创作
想用它写投标书、生成营销文案？放弃吧。Agent Express的LLM层是轻量级的（官方未公布型号，但实测参数量约7B），专为“检索-结构化-润色”设计。它没有足够的上下文窗口处理万字文档，也没有微调能力适应不同文风。这类任务，老老实实用Dify+Qwen2.5-72B，虽然要写点代码，但结果靠谱。

红线二：别指望它理解复杂因果链
用户问：“如果电压升高10%，按照第5.2.3条，导线截面积需要增加多少？”这个问题涉及物理公式推导，Agent Express只能返回“第5.2.3条原文”，无法计算。它的定位是“知识检索器”，不是“推理引擎”。真要实现，得在PolarDB里建一张 voltage_area_rule 规则表，把各种工况映射成SQL，再让Agent Express调用。

红线三：别绕过数据库权限做“伪智能”
有客户想绕过PolarDB，直接让Agent Express连MySQL。官方明确不支持。因为Agent Express的RLS、审计日志、SQL执行计划监控，都深度依赖PolarDB内核。强行对接其他数据库，等于卸掉刹车开高速。

那么，它的黄金战场在哪里？我总结为“三有”场景：

• 有明确知识源 ：PDF/Excel/数据库表，内容结构化程度高；
• 有确定性答案 ：问题能归结为“查某条文”“取某个值”“比对两个字段”；
• 有现有系统集成 ：需要嵌入OA、CRM、钉钉等，且对响应时长敏感（<3秒）。

比如某汽车零部件厂，用它做了“供应商质量条款查询智能体”：上传《TS16949质量协议》PDF，业务员在ERP里点一下，就能查到“某供应商的PPAP提交周期是30天还是45天”。这个场景，Agent Express三天上线，Dify要两周，自建LangChain要一个月。这就是无代码的真正价值：把AI从“技术项目”变成“业务功能”，让价值交付周期从月级压缩到小时级。

我个人在实际操作中的体会是：别把它当成一个AI玩具，而要当成一把“数据库手术刀”。你不需要成为AI专家，但必须是个懂业务的DBA——知道哪些数据该放在哪张表，哪些字段该建索引，哪些权限该配给谁。当AI能力被封装成SQL可管理的对象时，企业AI落地的最后一公里，才真正被打通。