PolarDB Agent Express 这个名字最早是我在一个做数据平台的群里看到的第一反应是又一个带 Agent 后缀的营销词。后来把控制台从头点了一遍又拿本地自己搭的 OpenClaw 版本对着比了一轮判断变了它想解决的并不是怎么写出一个 AI Agent而是怎么让一个 AI Agent 在生产环境里活过三个月。这两件事的难度差着量级。阿里云把 PolarDB 作为底座、把 OpenClaw 作为 Agent 运行时内核封装成一个企业级 AI Agent PaaS 平台本质上是在补一段被长期忽视的工程债模型能力已经够用缺的是会话状态持久化、工具权限治理、上下文预算、成本可视化和灰度发布这一整套运维面。自建过 Agent 的人应该有体会Demo 跑通只花了半天剩下两个月全花在这些看不见的地方。这篇内容我按六个实操视角拆平台把哪部分力气使在了刀刃上、OpenClaw 在里面的真实角色、Skill/Memory/MCP 三件套怎么落到数据库、从零跑通的路径、企业级细节里容易翻车的点、以及什么场景其实不该硬上。适合已经写过几版 Agent 但被生产问题卡住的人也适合刚入门想直接学一套规范做法的读者。1. 自建 Agent 卡在哪这个平台就把力气花在哪1.1 自建 Agent 普遍停在三个半成品状态我见过的自建 Agent 项目绝大多数死在三个地方。第一个半成品是会话状态。Demo 里用一个内存字典存历史消息重启就丢上了生产发现多副本部署之后用户在 A 副本聊了半句下一次请求落到 B 副本Agent 直接失忆。有人用 Redis 顶前两周没问题等会话历史长到几十 KBRedis 里塞满了 JSON排查问题的时候连一条完整会话都捞不出来。第二个半成品是工具调用治理。工具函数写完就注册进去谁都能调没有权限分级没有超时没有审计。Agent 自己决定调用哪个工具一旦某个工具的描述写得含糊模型就会在错误的场景下反复调用它日志里刷满了看不出来是报错还是正常的长文本。第三个半成品是成本与风险不可见。这个最要命。一个 Agent 一天烧掉多少 Token、哪些请求触发了超长上下文、哪个用户在用 Agent 干和业务无关的事情全靠月底看账单猜。等发现异常已经花掉的钱追不回来。1.2 PaaS 化真正剥离出去的是运行时治理理解 PolarDB Agent Express 的价值关键是把Agent 开发和Agent 运行分开看。开发是你写 Skill、写提示词、接工具运行是会话怎么存、副本怎么扩、工具权限怎么控、上下文怎么裁、成本怎么统计。开源框架在前者做得很顺手在后者基本是一片空白因为这部分和云厂商的基础设施强绑定社区项目没有动力也没有条件去做。阿里云的做法是把后者整体收进平台层Agent 定义是一个受管的资源对象会话记忆落到 PolarDB 里成为可查询、可回溯的数据工具执行跑在受控沙箱内上下文预算、并发、超时这些参数在控制台上可配、可观测。你在本地改一行代码要重启进程才能验证的事情在平台上是一次配置变更、一次灰度。这里有个隐含的收益容易被忽略记忆变成了结构化数据。会话记忆不再是某个 Redis Key 里的一坨 JSON而是数据库里的行。这意味着你可以对它做 SQL 查询、做数据脱敏、做归档策略、做合规审计。对于需要Agent 说过什么、依据是什么能拿出凭证的业务场景这一点比模型能力重要得多。1.3 谁现在就该上手谁可以先等等如果你的团队正在做的是内部知识问答、工单分类、数据查询助手、流程审批辅助这类错了也不致命的场景现在上手成本最低也最容易拿到收益因为这类场景对准确率的容忍度高但对接入速度、权限收敛的要求高正好是平台层擅长的。如果你做的是核心交易链路、资金操作、自动化运维这类错一次就出事故的场景我的建议是先把它用在只读环节——比如让 Agent 负责诊断、检索、生成变更方案最终执行仍然由人来点。等积累够多的观测数据、工具调用的失败模式摸清了再逐步放开写权限。这个节奏不是保守是被坑过之后的正常反应。2. 拆开看 PolarDB Agent Express 的四个层面2.1 控制面Agent 的注册中心与生命周期开关控制面做的事看起来最平淡但它是整个平台能不能用的前提。Agent 在这里被定义成一个有版本号的资源包含名称、调用的模型、绑定的 Skill 列表、可访问的 MCP 工具集、记忆策略、限额策略。定义完可以发布成一个稳定的端点外部应用通过 SDK 或 HTTP 调用不需要关心后面跑在哪个副本上。版本号这件事值得单独说。Agent 的行为对提示词极度敏感改一句系统提示输出风格可能完全变样。如果平台没有版本管理你会遇到上周答得挺好这周怎么变傻了却无从对比的尴尬。有版本之后可以做到新版本只对 5% 流量生效观测指标不掉再全量出问题一键回滚到上一个版本行为差异可以直接 A/B 对比。另一个容易被低估的是环境隔离。开发、测试、生产三个环境的 Agent 定义应该完全独立但共享同一套 Skill 代码仓库。我见过团队直接在线上调提示词调完顺手保存结果把一个只对内部员工开放的查询工具暴露给了外部用户。控制面的环境隔离不是为了好看是为了让这种手滑有后果可控的边界。2.2 运行时会话循环、沙箱和工具执行器运行时是 OpenClaw 真正发挥作用的层。一个会话请求进来之后运行时要完成一整条链路拉取历史记忆、组装上下文、调用模型、解析模型返回的工具调用意图、在沙箱里执行工具、把结果回填、再次调用模型直到模型给出最终回答或触发终止条件。这条链路里的每一步都有工程细节。沙箱这块我要多说一句因为它是最容易出安全问题的环节。Agent 调用工具本质上是把一段由模型生成的参数传给一段代码执行。如果这段代码能访问任意网络、能读写任意路径那么一次提示注入就可能导致数据外泄。企业级运行时必须有网络出口白名单、文件系统隔离、单次执行超时、执行资源上限。这些在本地用 OpenClaw 跑的时候你感觉不到一上生产就是硬需求。工具执行器的另一个职责是参数校验。模型生成的参数格式对不对、字段有没有越界、数值范围合不合理必须在执行前拦一道。我踩过一个坑一个查询工具的参数是日期字符串模型在某次回答里给成了自然语言上个月代码里没校验直接拼进查询条件报了个看不懂的错排查了半小时才发现是参数问题。加上 JSON Schema 校验之后这类问题在入口就被拦下返回给模型的是一条明确的格式错误提示模型自己会纠正。2.3 数据面为什么记忆最终要落回 PolarDB把 Agent 的会话记忆、用户画像、工具调用日志放进关系型数据库是一个看起来不够时髦但实际很务实的选择。向量库适合做语义检索Redis 适合做瞬时缓存但它们都不适合承担可审计、可事务、可关联查询的职责。而 Agent 在生产环境里恰恰需要这三样。举个具体例子客服场景里要查某个用户过去一个月内 Agent 给出的所有涉及退款的承诺。如果记忆在 Redis 里是一堆 JSON这个查询要么做不了要么得把所有会话捞出来在应用层过滤。如果记忆在 PolarDB 里是结构化的会话表和消息表一条 SQL 就能出结果。维度本地自建内存/Redis/单机文件平台化数据面多副本一致性需要自己实现容易出错天然一致副本无状态会话回溯靠日志拼凑常缺字段结构化查询可关联用户与工具调用数据脱敏事后处理容易漏存储前按策略处理归档与成本手动清理容易堆积按策略分层存储合规审计难提供完整链路凭证可导出完整调用链这个对比里最值钱的一行是副本无状态。Agent 服务一旦无状态扩容缩容就变成了纯粹的副本数调整和会话数据没有耦合。我之前的项目里因为会话状态在本地内存扩容时必须做一致性哈希缩容时又要把粘住的会话迁移出去运维复杂度直接翻倍。2.4 三层之间的边界该怎么划划边界的经验只有一条凡是需要跨请求、跨副本、跨版本保持一致的东西都放数据面凡是描述Agent 长什么样的东西都放控制面凡是每次请求都要跑的临时代码放运行时。按这条线去分很多争论会自然消解。比如提示词模板放哪儿——它是定义的一部分放控制面随版本走。用户上传的文档放哪儿——它是数据放数据面并且要有生命周期策略。临时的中间计算结果——放运行时内存不要落库。3. OpenClaw 在里面扮演什么角色为什么是它3.1 OpenClaw 的三个核心抽象值得单独理解OpenClaw 作为一套开源的 AI Agent 运行时框架它的设计里最值得借鉴的是三个抽象。会话循环负责模型—工具—模型的往复推进直到达成终止条件工具契约把外部能力描述成带类型的可调用对象让模型能理解什么时候该用哪个技能包把一组相关工具、提示和资源打包成可复用的单元。这三个抽象的价值在于它们都是可替换、可组合的。会话循环的策略可以换是简单往复还是带规划工具契约的实现可以换本地函数还是远程 MCP 服务技能包可以按业务拆分。平台把它选作运行时内核看中的应该正是这种正交性——内核保持轻治理能力在外面加。学习 OpenClaw 的最好方式是先在本地跑起来手动触发一次工具调用把完整的事件流打出来看一眼。你会看到模型输出里怎么描述工具意图、运行时怎么解析、工具返回怎么回填。把这条链路在脑子里建立起来之后再看平台上的配置项每个参数对应链路的哪一段就很清楚了。3.2 开源版直接进企业会缺哪几块我把本地 OpenClaw 拿去给一个企业内网环境做试点时缺的东西非常明确列一下给准备走这条路的同学参考身份与密钥管理。本地版靠环境变量塞 API Key企业里要接统一的密钥服务还要做到密钥不下发到运行时进程。资源配额。本地版没有并发上限一个失控的循环能把机器打满。企业环境必须能按 Agent、按用户、按租户设限额。审计链路。本地版日志是给人看的企业要的是可导出、可追溯、能对上谁在什么时候让 Agent 调了什么工具的记录。多租户隔离。同一个运行时进程服务多个业务方的时候记忆、工具、配额都不能串。灰度与回滚。本地版改配置就是改文件重启企业要的是不改代码就能切流量。这五块每一样单拎出来都不算特别难但凑在一起就是一个平台的工作量。PolarDB Agent Express 本质上是把这五块做成了产品能力。3.3 和纯自建 OpenClaw 的真实差异在哪里我不建议把关系理解成平台版 vs 开源版谁更强。真实差异在责任边界。自建的时候会话存储的一致性、沙箱的隔离强度、配额的有效性都是你自己的责任出问题也是你自己扛。用 PaaS这些变成平台承诺的能力指标你只需要关注 Agent 的业务逻辑写得对不对。反过来自建的优势是完全可定制。如果你的场景需要非常特殊的会话循环策略比如带人工介入的多轮审批流、或者需要嵌入自己的调度系统平台提供的标准循环可能不够用。这时候自建的灵活性就体现出价值。我的实际选择是混合核心的、需要深度定制的 Agent 用自建外围的、需要快速铺开的 Agent 用平台。两者共享同一套工具契约定义保证行为一致。4. Skill、Memory、MCP真正决定 Agent 好不好用的是这三样4.1 Skill 的边界划在一件事上Skill 最容易犯的错是做得太大。我见过一个客户服务Skill里面塞了查询订单、修改地址、发起退款、转人工十几个工具。结果模型的工具选择准确率很低因为工具描述之间的语义边界模糊改地址和发起退款在描述里都提到了订单号模型经常选错。正确的做法是一个 Skill 只对应一类操作并且这类操作共享同一套权限模型和失败处理策略。查询类和写入类必须分开因为它们的权限等级、幂等要求、审计要求都不一样。按这个粒度拆工具描述会变得非常清晰模型的准确率会明显上升。Skill 描述里我建议固定包含四段内容这个 Skill 解决什么问题、什么时候该用、什么时候不该用、调用后会发生什么副作用。第三段什么时候不该用是最多人漏掉的但它对减少误调用极其有效。写清楚这个工具仅用于已支付订单未支付订单请使用 XX 工具能省掉大量排查时间。4.2 Memory 分层会话记忆、用户记忆、语义记忆把记忆当成一坨文本存起来是新手最典型的做法。生产环境应该分三层每层的生命周期和检索方式都不同。会话记忆是当前这轮对话的上下文生命周期就是会话本身超出预算的部分做摘要压缩。用户记忆是跨会话的长期偏好和事实比如用户所在的部门、常用查询口径、上次沟通的结论生命周期以月计需要定期校验时效。语义记忆是从历史交互里提炼出的可检索知识通常用向量方式存储用于找相似历史案例这类需求。三层分清楚之后最直接的好处是成本可控。每次请求不必把所有历史都塞进上下文而是按需检索。我实测下来一个日均千次调用的问答 Agent把全量历史注入改成按需检索三层记忆之后平均上下文长度降了六成以上首字延迟也明显改善。4.3 MCP 接入的正确姿势与常见误用MCP模型上下文协议解决的是工具怎么标准化接入的问题让 Agent 可以连接外部的工具服务而不必把每个工具都写成代码。这个方向是对的但接入时有几个坑要注意。第一不要把 MCP Server 当权限边界。MCP 只是传输和描述的协议它不负责鉴权。企业环境里必须在平台层做一层工具白名单明确哪个 Agent 能访问哪个 MCP Server 的哪些工具。指望 MCP Server 自己控制权限等于把门禁交给了访客。第二工具数量不是越多越好。接十个 MCP Server、暴露两百个工具模型的工具选择准确率会断崖式下跌。可行做法是分组加载按当前会话的主题动态挂载相关的工具集而不是一次全塞进去。第三远程 MCP 的超时和降级要提前设计。MCP Server 是外部服务可能慢、可能挂。平台层要有单次调用超时、重试上限和降级策略。我的经验值是只读工具超时设 5 到 10 秒失败直接告诉模型该工具暂时不可用写工具超时设长一点但要配幂等不能让模型重试导致重复执行。下面是一个我在实践里用的工具契约定义样例带上了副作用标记和权限标签{ name: query_order_status, description: 查询已支付订单的当前物流与支付状态。仅用于已支付订单未支付订单请使用 query_unpaid_order。, side_effect: read_only, permission_scope: order:read, timeout_ms: 8000, parameters: { type: object, properties: { order_id: { type: string, pattern: ^[0-9]{16,20}$ }, with_logistics: { type: boolean, default: true } }, required: [order_id] } }这段定义里最值得注意的是side_effect、permission_scope和timeout_ms三个字段。它们不是给模型看的是给运行时和治理层看的让平台能够在执行前做权限校验、在超时后主动中断、在审计时快速分类。5. 从零跑通第一个 Agent 的完整路径5.1 凭证与环境准备别在这步省事上手第一步容易出问题的不是 Agent 本身是凭证管理。我的建议是把三类凭证严格分开模型调用的凭证、数据面访问的凭证、外部工具服务的凭证。三者用途不同、轮换周期不同、暴露面不同混用一个后果很严重。在阿里云的环境里通常是走统一的访问控制体系而不是把长期密钥写进配置文件。如果你的 Agent 需要访问 PolarDB最好是通过平台提供的连接方式而不是自己维护一套账号密码。这一步多花的半小时会在后面出安全审计问题时省掉几天。环境准备还包含一件常被忽略的事把本地开发环境的 Agent 定义导出成配置文件纳入版本控制。提示词的改动历史应该和代码一样可追溯。我现在的做法是把 Agent 定义写成 YAML提交到代码仓库通过流水线推送到平台而不是在控制台上手改。手改的后果是没人知道线上跑的到底是哪一版。agent: name: order-support-agent version: 1.3.0 model: default-chat memory: session_ttl: 24h user_memory: enabled semantic_recall: top3 skills: - order-query - logistics-track mcp_servers: - name: internal-tools tools_allow: - query_order_status - query_unpaid_order limits: max_tool_calls_per_turn: 5 max_context_tokens: 16000 qps_per_tenant: 205.2 写第一个 Skill先把只读链路打通第一个 Skill 一定要选只读的。原因很实际只读链路的错误成本低你可以放心让它在真实流量上跑快速积累工具调用的准确率数据。写 Skill 的顺序我推荐这样把工具函数的输入输出定死写成 JSON Schema包括字段类型、取值范围、必填项。写一段 50 到 150 字的描述包含用途、使用时机、禁用条件、副作用说明。在本地用构造好的输入直连工具函数确认逻辑正确、错误返回规范。再通过 Agent 触发观察模型是否在正确的场景选中它。记录被误触发的案例回头修描述而不是修代码。第 5 步是重点。工具选择错误九成情况下是描述问题不是模型问题。我做过一轮统计在二十多个误调用案例里只有两个是模型能力导致的其余都是描述里缺少禁用条件或者两个工具的描述语义重叠。5.3 挂载 MCP Server 的实操顺序接 MCP 的时候不要一次全接。我的做法是先用一个最无关紧要的 MCP Server 走通全链路确认连接、鉴权、工具枚举、调用、错误返回都正常再接业务相关的。这个热身步骤能帮你把环境问题网络出口、证书、超时和业务问题分离开排查效率差很多。接好之后立刻做两件事。一是限制工具白名单明确只允许暴露哪几个工具其余即使 MCP Server 提供了也不挂载。二是记录工具调用日志至少包含工具名、参数摘要、耗时、返回状态。这份日志是后面做客流分析和成本归因的基础后补非常痛苦。5.4 灰度发布与观测口径的确定上线前必须定好观测口径否则你不知道该看什么。我一般定四个核心指标指标含义健康区间参考任务完成率用户未追加追问且会话正常结束的比例逐版本对比不低于基线工具选择准确率正确的工具调用占全部调用的比例越高越好低于阈值需修描述平均工具调用轮次单次会话中的工具调用次数异常升高通常意味着描述歧义单次会话 Token 消耗平均每个会话的上下文成本关注长尾分布不看均值灰度策略我用的是最朴素的做法新版本先接 5% 流量跑够一个完整业务周期比如一天四个指标都不掉再放到 30%、100%。回滚按钮必须在手边而且回滚要能在一分钟内生效。6. 企业级落地绕不开的四个硬细节6.1 上下文预算要按最坏情况算上下文预算不能按平均值算。Agent 的上下文长度分布是长尾的一次异常会话可能比普通会话长十倍。我踩过的坑是按平均值配了 16K 的预算结果某天一个用户连续追问了四十轮上下文撞到上限历史上的关键信息被截断Agent 开始重复问已经回答过的问题用户体验直接崩了。正确处理方式是分层处理上下文最近几轮保留原文较早的轮次做摘要更早的只保留结构化要点比如结论、约束、用户确认过的关键参数。摘要压缩要有触发条件比如当累计 Token 超过预算的 60% 时启动。同时给会话设一个硬性的轮次上限超出的部分走归档需要时再检索回来。6.2 幂等和重试写操作必须自己兜底模型调用的工具可能超时超时之后模型会倾向于重试而重试一个已经成功但响应丢失的写工具就是重复下单、重复退款。这个问题在平台层往往解决不了因为平台不知道你的业务幂等键是什么。我的做法是所有写工具的入参里强制带一个由运行时生成的操作标识工具实现侧用这个标识做去重表。第一次执行写库并记录标识第二次同标识直接返回上次结果。同时把写工具的重试策略设为不自动重试让模型拿到明确的结果未知返回由业务侧决定下一步。这个策略看起来笨但它把可能重复变成了需要人工确认风险等级完全不同。6.3 成本归因要细到 Agent 和租户月底看到账单超了才去查原因是最被动的状态。可行做法是在运行时给每次模型调用打上标签Agent 名称、版本号、租户标识、会话标识。这样成本可以按任意维度聚合。我实测过一个案例某个 Agent 的成本突然涨了三倍按标签一查是某个租户在批量调用一个会触发长上下文检索的工具定位时间不到十分钟。另外要关注上下文复用率。如果每次请求都是全新的上下文成本会非常高。把系统提示、工具描述这些固定部分做缓存能省掉相当可观的重复计算。这部分收益取决于平台是否支持提示词缓存值得在选型时确认。6.4 故障降级要有明确的收敛路径Agent 出故障时的降级路径必须提前设计不能临时发挥。我一般设三级第一级是单个工具不可用时让模型明确告知用户该能力暂不可用并给出替代路径第二级是模型服务不可用时切到固定的兜底话术并把会话转人工第三级是整体不可用时外部应用侧要有开关能直接关闭 Agent 入口回到原来的交互流程。第三级最容易被忽略但它其实是最后的安全网。没有这个开关Agent 出问题时你只能眼看着它在生产环境里制造错误回复。7. 联调阶段我踩过的几个坑与排查思路7.1 工具描述写成散文模型开始乱调有一个查询工具我最初写的描述是用于帮助用户获取订单相关的各类信息支持多种查询场景。结果这个工具被调用的频率远超预期很多本该走用户信息工具的问题也被它接走了。排查的时候我把所有调用它的会话拉出来看发现模型的调用理由都是用户问的是订单相关问题而描述里恰好只强调了订单。修复方式是把描述改成三段式用途一句话、适用条件一句话、禁用条件一句话并且明确写出查询用户基础资料请使用 query_user_profile。改完之后误调用率下降非常明显。工具描述不是给人看的文档是给模型看的接口契约措辞的精确度直接决定行为。7.2 长会话内存暴涨与截断策略的坑前面提到过上下文撞上限的问题这里说排查过程。现象是某些会话在第十几轮之后开始出现忘记前面说过的话同时运行时内存占用曲线呈阶梯状上升。排查链路是这样先看单会话的上下文长度分布发现长尾会话的长度是普通会话的十几倍再看截断逻辑发现截断是从最早的消息开始整条丢弃而最早的几条里恰好包含用户最初的需求描述和确认过的关键参数最后确认是截断策略的问题不是模型的问题。改成摘要最早几轮并保留结构化要点之后问题消失。这个坑的教训是截断顺序不能简单按时间先后要先保系统提示和用户最初的需求再保最近的交互中间部分才做摘要。7.3 权限越界的两种典型形态第一种是横向越界Agent 被租户 A 调用却检索到了租户 B 的记忆。这类问题通常出在数据面的过滤条件上查询记忆时忘了带租户条件。检测方式是构造跨租户的测试用例在灰度阶段就跑一遍。第二种是纵向越界一个只应该做查询的 Agent通过某个通用工具拿到了写权限。这类问题出在工具授权粒度太粗把读写工具打包在同一个 Skill 里。这两种越界的共同点是不主动测就不会暴露。所以我的做法是把跨租户查询和越权写入做成固定的回归测试用例每次版本发布前跑一遍。7.4 冷启动与并发突刺的处理运行时的冷启动问题在 Agent 场景下比普通服务更明显因为初始化要做的工作很多拉取 Agent 定义、加载 Skill 和工具描述、建立数据面连接。如果这些都在第一个请求时同步做首字延迟会非常难看。缓解方式有两个方向。一是预热在流量低谷期主动触发一次轻量调用把运行时的定义和连接热起来。二是并发突刺限流宁可让部分请求排队也不要让所有请求同时去初始化导致级联超时。限流的粒度要按租户做避免一个租户的突发流量拖垮其他租户。8. 什么场景不该硬上以及我的判断标准8.1 三类不适合直接上 Agent 的场景第一类是规则明确、输入结构固定的流程。比如一个只有固定几个字段的表单校验用传统代码实现又快又稳引入 Agent 只会增加不确定性和成本。判断标准很简单如果你能把所有分支穷举出来写成一个决策表那就别用 Agent。第二类是对确定性要求接近 100% 的链路。Agent 的输出天然带随机性即使加了严格的输出格式约束仍然存在极小概率的异常。资金结算、库存扣减这类操作让 Agent 生成方案、由确定性代码执行是更合理的分工。第三类是数据边界极其严格、连内部服务都不允许访问的场景。Agent 的价值来自连接信息和工具如果这个前提不存在它的价值也就没了。8.2 这类场景反而特别适合我最看好的三类场景分别是多系统信息整合的问答需要跨几个系统取数并组织语言、非结构化文本的分类与抽取工单分类、合同要素提取、人机协同的流程辅助生成诊断报告、起草回复草稿、给出变更建议。这三类的共同点是有明确的人工兜底环节Agent 出错可以被拦住同时它省下的人力又实实在在。判断某个场景值不值得做我通常问三个问题这个任务每周重复多少次每次人工处理要多久出错一次的实际损失有多大前两个答案相乘是收益第三个是风险。收益明显大于风险就值得试。8.3 一个实用的推进节奏最后说一个我在实际项目里用得比较顺的推进节奏。第一阶段只做只读目标是打通链路并积累观测数据第二阶段加入低风险写操作配幂等和人工确认第三阶段做多 Agent 协同和更复杂的编排。每个阶段结束都要复盘四个指标任务完成率有没有提升、工具选择准确率是多少、单次会话成本是多少、出现了几类新问题。这四个数字是决定要不要进入下一阶段的唯一依据而不是感觉效果不错。我见过太多项目在没数据支撑的情况下盲目扩场景最后 Agent 覆盖了几十个业务点但没有一个真正跑得稳。小而稳地跑通一个场景、拿到真实数据比铺开十个半成品有价值得多。