痛定思痛，AI Agent 给我的教训

前言

本文反思了在生产环境中构建AI Agent产品的教训。此前我创建了一个案例分析AI系统，但认识到它更像是一个工作流而非真正的Agent。在探索LLM能否自主决定赔付率分析方向时，结果令人失望。

业务背景

企业AI应用可以分为五种行为类型：

场景类型	核心技术	关键挑战	保险示例
事实提取	查询 + LLM理解	复杂术语、歧义、冗余、幻觉	”本月赔付率增长了吗？“
推理分析	查询 + LLM推理	专家知识注入、结果不稳定	”分析最近赔付率上升原因”
流程推进	LLM理解 + CRUD	流程复杂性、语言精度、用户体验	”引导保单需求确认”
计算处理	数学运算、数据处理	数据准确性、算法效率、异常值处理	”计算风险系数分布”
综合诊断	以上全部	高复杂度、多维融合、可解释性	”评估大额理赔欺诈风险”

赔付率分析项目最初定位为推理分析类，结构为规划 → 执行 → 表达。

赔付率异动分析

规划阶段

赔付率分析需要考察四个关键维度：宏观经济环境变化、精算假设变化、风控策略变化、经营策略变化（营销渠道、客群细分、产品升级）。

最初注入了大量专家知识并将分析方向限制在六个以内。这导致LLM偶尔会以”小概率”违反四方向约束。取消专家知识约束减少了违规，但产生了新问题——模型会强行匹配分析方向或生成语义变体，导致下游工具执行中断。

引入DAG（有向无环图）结构和子问题来模拟专家推理，进一步使输出不稳定。即使明确指示保持提供的方向不变，LLM偶尔还是会生成额外的子方向或语义变体，导致前端渲染失败。

结果： 彻底放弃了LLM驱动的规划，回归传统开发方式。

执行阶段

将规划方向转化为工具调用或SQL查询，然后用LLM总结结果。结构到语言的转换成功率较高，但早期大量注入专家知识产生了问题：用户不喜欢超出实际数据的信息，而且LLM会以”小概率”倾向模拟缺失数据。

最佳实践： 当数据不可用时，简单回复：“未找到与xxx相关的数据。“

表达阶段

两个核心需求：

输出事实数据 — 单次LLM处理可以保留事实，但二次处理会显著降低完整事实输出的概率。不如直接将执行结果作为事实数据输出。
输出总结信息 — 关键挑战：LLM容易忽略执行结果中标记的假设/推断信息，将其作为确定结论报告，摧毁可信度。

当规划方向与可用数据源不完全匹配时，执行阶段会标记”可能”的关系。LLM要么完全忽略”可能”这个词，要么需要明确提示排除此类信息——导致事实丢失。

更深层洞察： AI数据分析是对既有功能的包装。如果原始功能产生的数据不完整或不正确，AI不会增加价值，反而会产生比没有更糟糕的输出。稳定的拒绝响应优于编造。

再次反思

产品是用来解决问题的

“AI是一个好工具，但如果它在某些场景下表现不好，你应该考虑替换它。” 应该把AI当作可替换的基础设施，而不是假设它必须解决每个问题。

Prompt二义性

丰富的prompt反而带来更高的歧义风险。三类歧义：

1. 语义歧义 — 同一术语在不同上下文中含义不同；指令适用范围不明确；术语定义不一致。

2. 格式歧义 — 数据格式规范不一致；输出结构模板各异；标点使用差异。

3. 逻辑歧义 — 条件判断冲突；优先级规则不明确；异常处理矛盾。

例如：“保留4位小数” + “将比率转换为两位百分比”就会产生歧义。

解决方案： 让LLM评审prompt修订中的清晰性问题。对prompt实施单元测试和版本控制。

重视小概率表现

永远不要忽视LLM对预期输出的任何偏离。通过prompt修改来逐个修补问题只是解决了眼前的问题，但在规模化时暴露了根本问题。

核心论点： AI项目从根本上需要将工程能力与高质量数据结合——两者缺一不可。Demo一周完成；令人满意的生产结果需要一个月甚至更长。

王艺辉

如何快速创建领域Agent — OneAgent + MCPs 范式

从单一LLM调用到多智能体系统的演进，提出OneAgent + MCPs范式：基于强大基础Agent结合领域MCP，替代为每个场景搭建烟囱式多智能体系统的传统方式。

付权智

Agent 管理学：AI Coding 的确定性边界

过去一年，我们在 Agent 管理学论坛里和上百位开发者一起踩坑、复盘、迭代。这篇文章是阶段性总结：AI Coding 不是一个技术问题，而是一个管理问题。从需求端、执行端到验收端，在每一段建立明确的契约，就是 AI Coding 的确定性边界。

瑞典马工

如何确保AI软件工程品质？

Agents 特区社区邀请19位AI编程先行者参与线上圆桌研讨。与会者来自券商、医疗器械、K12教培、支付宝、开源基础设施等背景迥异的领域。本文探讨概率性系统如何通过确定性约束和独立性验证确保AI代码品质。

前言