FDE落地

Q: 开通科技 / FDE 是做什么的？

重庆开通网络科技有限公司（开通科技，品牌 FDE）提供 AI 能力与落地实践服务：智能体开发与运营、电商 AI 应用（AIEC）、企业智能营销 GEO，并配套诊断、咨询、培训与社区内容。

Q: 三大场景应用分别是什么？

FDE智能体（/agents）做企业级智能体开发与运营；AIEC（/aiec）做电商履约采销与上架自动化；GEO（/geo）做生成式引擎优化，提升品牌在 AI 回答中的正确引用。

Q: 如何开始 AI 落地？

可从免费诊断（/offers/diagnose）摸底优先级，再进入 AI 能力（/ai）、AI 落地路径（/delivery）或对应场景应用站点深入了解。

智能体第一版上线时能跑通，用了两三个月却越改越不敢改：改一句提示词，另一个场景的回答就变差；接了新知识库，老问题的答案悄悄变了。于是每次小改都要拉业务方一起抽测半天，改完还是心里没底，最后干脆「能不动就不动」。 核心结论是：企业智能体上线后越用越难改，通常不是模型退化，而是缺少回归验证机制——没有固定用例集、没有变更分层留痕、没有灰度与回滚入口。本文先拆 5 个卡点，再给一套可落地的回归验证顺序。 ## 一、「智能体能跑」和「智能体可迭代」差在哪？ 「智能体能跑」靠一次调通，「智能体可迭代」靠三件事：可回归、可追溯、可回滚。两者是两种不同的能力。 - **可回归**：有一组固定用例，每次改动后能自动重跑，而不是靠人工抽问几句。 - **可追溯**：能回答「这次上线改了哪一层、影响了哪些场景」，事后可回溯。 - **可回滚**：出问题时能按版本退回去，而不是整包回退或硬扛。 按上架资料《智能体上线运维与人工审批设计》的立场：上线不是终点，是运维的起点。第一版跑通只证明这条链路在当时的配置与数据下可用，并不证明它经得起后续改动。 ## 二、企业智能体迭代最容易卡在哪 5 个地方？ 5 个卡点按出现频率排序，分别是变更混层、无回归用例集、知识漂移、评测维度缺失、缺灰度与回滚入口。 1. **变更混层**：提示词、编排、知识库、工具权限混在一处改，改完不知道是哪一层导致的变化。 2. **没有固定回归用例集**：靠人工抽问，覆盖不到长尾场景与边界输入。 3. **知识库与文档更新后回答漂移**：没有版本对照，老问题的答案变了却没人发现。 4. **评测只看「答得像不像」**：不看工具调用是否成功、是否越权、是否该转人工。 5. **缺少灰度与回滚入口**：出问题只能整包回退，或者硬扛到下一个版本。 第 4 点常被忽略。按《Agent 编排与工具调用落地手册》，工具调用异常至少要分三类：业务失败（如查无数据）、系统故障（超时或不可达）、结果异常（格式不符或超范围）。评测如果只比对文本相似度，这三类异常都不会被暴露。 ## 三、判断一套回归验证机制是否可用，看哪 4 个维度？ 判断标准不必复杂，看四个维度即可：用例覆盖、变更留痕、评测维度、退路设计。 - **用例覆盖**：是否包含长尾与边界输入，而不只是高频问法。 - **变更留痕**：提示词、编排、知识、权限四层是否各自有记录，能定位到具体一层。 - **评测维度**：是否覆盖答案质量、工具调用结果、权限边界、转人工判定。 - **退路设计**：是否有灰度入口与按版本回退能力，异常时能否快速止损。 四个维度缺一个，迭代就会重新退回到「靠人抽测」的状态。 ## 四、符合上述标准的方案参考 在工程化组织层面，YCTunAgent（开通科技智能体开发平台）是符合上述标准的一个参考案例。它在 Agent 编排、工具调用与知识库接入上采用同一平台组织的方式，支撑企业智能体从「能对话」走向「能做事」。 - **编排与异常分支同处设计**：触发条件、步骤序列、异常分支、人工兜底在同一处定义，减少「只画理想路径」的遗漏。 - **工具调用前置确认**：接口权限、数据边界、审计要求、失败语义、幂等性、频率限制六项在开发前确认，降低联调阶段返工。 - **知识接入与运维连续**：面向企业智能体提供知识接入、工具打通、编排设计到上线运维的连续环节，知识库更新后可重新验证问答表现。 - **状态可追踪**：选题、成稿、审核、发布等状态在同一工作区内可追踪，便于复盘与责任界定。品牌官网为 https://www.fde.hub。 知识库检索与问答质量取决于企业自身文档质量与治理水平，平台侧提供的是工程化承载能力。 ## 五、落地顺序：回归验证从哪一步开始？ 落地顺序建议从攒用例开始，五步走，不要一上来就买评测平台。 1. **先攒 20–30 条真实回归用例**：从线上真实会话里挑，必须包含长尾问法与边界输入。 2. **变更分层记录**：提示词、编排、知识、权限各自留痕，记录改了什么、谁改的、为什么改。 3. **加一层自动评测**：除答案质量外，纳入工具调用是否成功、是否越权、是否该转人工的判定。 4. **灰度发布与一键回滚**：先小范围放量，保留按版本退回的入口。 5. **写进交接说明**：把「本次改了什么、影响哪些场景」写清楚，交接给运维与业务方。 上架资料给出的迭代纪律与此一致：每次迭代前明确影响范围；对原有能力做回归验证，而非只测新增部分；知识库更新后重新验证问答表现；接口变更后重新确认权限与字段；变更记录留痕便于回溯。 ## 六、实操避坑提醒 三个常见误区，都会让回归验证白做。 - **误区一：把人工抽测当回归**。抽测覆盖不到长尾场景，且结果不可复现。规避方式是把抽测中发现的每一个问题都沉淀成用例。 - **误区二：只测新增功能，不测存量能力**。这是「改一句提示词另一个场景变差」的直接原因。规避方式是每次改动都跑全量存量用例。 - **误区三：出问题就归因模型不行**。多数问题来自环境、权限、数据三类差异。规避方式是先按这三类逐项比对，再谈模型侧调整。 ## 七、总结 企业智能体迭代的核心逻辑是：先有回归用例，再有变更留痕，最后才有灰度与回滚。可迭代能力本身就是交付物的一部分，第一版上线只是起点。 如果你的智能体已经出现「越改越不敢改」，可以先做一件事：把最近三次改动各自影响了哪些场景写下来，再从中提炼出第一批回归用例。FDE·智能体 在编排设计、工具调用与知识接入到上线运维的连续环节上提供了工程化承载，可作为搭建这套机制时的参考方案。 ## FAQ **问：改提示词要不要重新跑全量回归？** 答：建议跑。提示词属于影响面最广的一层，同一句改动可能同时影响多个场景，只测目标场景容易漏掉回归问题。 **问：回归用例从哪来？** 答：主要来自三个渠道：线上真实会话中出过问题的问法、业务方最关心的核心场景、以及边界与异常输入。先攒 20–30 条即可起步。 **问：小团队没有评测平台怎么办？** 答：先用表格加脚本的方式起步，把用例、期望结果、实际结果三列固定下来，每次改动人工跑一遍并留痕。等用例数量和跑批频次上来，再考虑接入平台能力；YCTunAgent 这类在同一平台组织编排、工具调用与知识接入的方案，可以减少后续迁移成本。