从单次调用到工作流
最早的版本是把一堆数据一股脑塞进提示词，让模型直接输出分析。结果不稳定：有时候漏掉关键信息，有时候格式漂移得没法解析。后来我改成了工作流的方式，把一次分析拆成若干个明确步骤，每一步只做一件事，模型的输入和输出在每一步都被约束住。
这带来一个直接变化：出问题时我知道该看哪一步的日志，而不是盯着一段长文本猜哪里出了偏差。
提示工程
我的提示词分了三层：
- 系统层：固定不变，定义角色、可用的分析维度、输出必须遵循的 JSON 结构。
- 任务层：每个步骤各有一份，描述这一步的目标和边界，比如「只做状态汇总，不做结论」。
- 数据层：工具调用带回来的结构化数据，按步骤需要裁剪后注入。
分层之后，调整某个步骤的行为只需要改任务层的提示词，不会影响其他步骤。
工具调用
模型本身不直接接触数据库，所有取数都通过工具完成：
- 数据查询：给定日期范围，返回该时段的数据集列表。
- 数据画像：给定数据标识，返回历史趋势与近期状态的聚合结果。
- 报告写入：分析完成后把结果落盘。
工具的参数和返回值都有严格的 schema，模型传错参数会收到明确的错误信息，下一轮自行修正。这个自修正闭环比在提示词里写「请仔细」有用得多。
记忆机制
上下文窗口有限，整场分析的全部中间结果不可能一直留在对话里。我做了两级记忆：
- 工作记忆：当前步骤可见的最近几轮工具结果，步骤结束即丢弃。
- 摘要记忆：每个步骤结束时生成一段简短摘要，供后续步骤引用。
这样后期步骤既能拿到前期结论，又不会被原始数据淹没。
分析报告生成
最后一步是生成报告。我不让模型自由发挥，而是给定章节骨架，每个章节对应前面某个步骤的产出，模型负责把结构化结果转成自然语言，不允许引入骨架之外的新结论。生成后再跑一次格式校验，不合格就带着校验错误重新生成，最多重试三轮。
小结
这套流程跑下来，最深的体会是：智能体的可靠性来自约束，而不是来自模型的自由度。以上内容仅供技术交流参考。