【企业 AI 研发平台落地踩坑实录系列-第三篇】问题从来不在提示词写得好不好

原创于 2026-08-22 21:05:59 发布 · 312 阅读

本内容遵循CC 4.0 BY-SA版权协议

系列：《企业 AI 研发平台落地踩坑实录》第三篇
在这里插入图片描述
上篇聊完"哪些不确定性能交给模型，哪些必须钉死在系统里"。这篇不灌方法论，就用一次真实的重做，把那条线接上地面。
同一套 AIETL 系统，我重做了三遍。三个数字先摆出来：
1.0：4 个 Agent + 2 个 Tool，6 份大提示词，约 2441 行；
2.0：1 个 MAIN + 5 个 Skill，文件反而涨到 36 份，约 5217 行；
3.0：还是 1 个 MAIN + 5 个 Skill，文件缩回 27 份，约 4687 行。
一个反差先抛给你：为什么"拆 Skill"之后，文件和规则反而翻倍？为什么第三版没有退回大提示词，却比第二版更轻？
答案不是"提示词写得好不好"，而是规则放在了哪一层。
在这里插入图片描述
1.0：用更多 Agent 对抗不确定性
第一版顺着传统软件分层的直觉，把流程拆成四个 Agent——PLAN 管计划调度、KNOW 管需求理解、SQL 管生成、CHECK 管检查，外面再配两个查库和检核的 Tool。
结构很好懂：业务有几个岗位，就建几个 Agent，每个一份大提示词，彼此用约定 JSON 交接。它确实解决了一件事——需求、查询、生成、检核不再挤在同一个提示词里。
但跑了一阵，新成本冒出来了。
每个 Agent 都要理解任务背景、都要知道流程走到哪、都可能生成面向用户的回复。交接协议越来越长，相同规则在多份提示词里反复抄。一个字段在 KNOW 里叫一种名字，到了 SQL 又得重新解释一遍。
更麻烦的是：流程责任并没有因为 Agent 变多而变清楚。多个 Agent 都在"理解全局"，只是各自理解了一遍。
1.0 的问题不是 Agent 多，而是把业务职责、流程状态和交互调度一起打散了。

2.0：方向对了，却被自己写重了
第二版回到一主多技能。MAIN 负责识别任务、调度 Skill、统一展示；长链路拆成五个 Skill：
etl-requirement-clarify 整理需求；
etl-evidence-collect 查表、字段、码值等证据；
etl-sql-create 生成或修订 SQL；
etl-check-ruler 优先调检核接口；
etl-md-write 把结果写成 PLAN 和 RECORD。
方向是对的：Skill 按业务职责拆，内部传结构化 JSON，用户看到的是需求卡片、证据卡片和 SQL，简单任务还能单 Skill 直达。
但这些正确方向，很快被一个问题淹没——为了让模型绝不走错，我把越来越多的控制逻辑写进了提示词。 第二版 5217 行，大半是这类"保险丝"。挑三个最疼的：
① MAIN 里养出一套"影子状态机"。 它维护 current_stage、resume_stage、repair_count，提示词里还画了完整状态迁移表。看起来像程序，实际仍由模型执行。上下文一压缩、输出一遗漏，状态就失真。我们写出了状态机的样子，却没拿到状态机的执行保证。
在这里插入图片描述
② 我建了规整的 specs/，平台却根本不加载。 每个 Skill 都有独立的输入输出 Schema 和契约。但平台的 Skill 加载机制只读取 SKILL.md 和关联资源。我以为模型会遵守的规则，可能压根没进上下文。问题不在 specs 这个名字，而在没先确认框架到底加载什么。
③ 简单查一个码值，模型能自己扩成循环。 第一次没查到，它开始试其他数据项、其他数据域、甚至找其他数据源。动机是"尽量帮用户"，但在企业数据查询里，这种主动性会越过事实边界。
后来我们明确：简单查询无记录就立刻转人工确认，数据源固定，不允许把 Schema 当数据源，也不允许自动找替代源。

在这里插入图片描述
转折点：停止猜平台
前两版最耗时的，不是业务规则复杂，而是一直在用提示词弥补未经确认的平台能力。
第三版之前，我们重新确认了一组听起来很土、却决定生死的事实：Skill 到底怎么加载执行、平台有没有 Redis 和 TodoList、哪些目录会被加载、JSON Schema 有没有程序校验、上下文压缩后到底保存什么、工具权限能否隔离……
这些没有"提示词工程"那么新鲜，却决定了设计能不能落地。
3.0：把规则还给真正的负责人
第三版没有推翻一主五 Skill，只是调整了规则归属。
状态和恢复交给平台。 Redis、TodoList 或任务状态负责长链路阶段与恢复，MAIN 不再维护一份与平台平行的运行上下文。
Skill 回到业务职责。 SKILL.md 只留定位、触发、输入边界、执行步骤、停止条件、红线。能由平台权限解决的，不再假装靠提示词控制。
**specs 合并进平台会加载的资源目录。** 输入输出契约没丢，只是放进按需读取的 references，按结构类、操作类、判断类分好。
内部结构和外部展示分开。 Skill 之间传原始结构化结果，用户看可读卡片。展示内容不能反过来当下游参数。
查询主动性限制在事实边界内。 每轮只跑少量独立查询，无记录立刻交用户，不无限扩大搜索。
3.0 不是单纯追求文件更少。完整业务规则和必要 Schema 都还在，减少的是重复规则、没人读的字段，以及写在没有执行能力那一层的"伪约束"。

三次迭代，留下三句话

先盘点平台，再画 Skill 架构。 别用理想框架设计现实里的 Skill。
写规则前，先找执行者。 状态由平台执行，业务判断由 Skill 执行，外部动作由 Tool 执行，真正会改变结果的业务选择才问用户。
内部结构化，外部说人话。 机器要稳定字段，用户要看懂结论，别让同一份文档同时服务两个目标。
所谓 3.0，不是提示词写得更高级了，而是终于知道哪些东西不该写在提示词里。
模型负责处理模糊，系统负责守住边界。两者各做擅长的事，企业 AI 才可能从演示走向真正可用。