分析类 Agent 很容易聊虚。
一开始大家都会说，它能问数，能分析，能生成报告，能帮业务发现问题。听起来都对，但如果真的要往项目里推，问题马上变硬：它和 BI 是什么关系？智能问数和经营分析怎么分？一个 Agent 到底需要哪些能力？质量怎么评？后续团队怎么复用？
我用 Codex 做“分析类 Agent 构建范式”时，最大的收获不是生成了几份文档，而是把这些问题从一团想法压成了一个工程。
这个专项最后形成了几类材料：项目主控说明、关键口径与决策记录、交付物目录、上下文续接包、项目规约、进展与成熟度管理，还有范式正文、可复用能力清单、脚手架方案、质量评测与运营优化方法，以及团队评审 PPT。
听起来像很多文件。其实它们不是为了显得正式，而是各自解决一个具体问题。
我是怎么一步步推进的
第一步不是写范式正文，而是写 01_项目主控说明.md。先把专项名称、背景、目标、职责边界和建设主线定下来。没有这个文件，后面每份材料都会往不同方向跑。
第二步，写 02_关键口径与决策记录.md。分析类 Agent 到底覆盖什么，不覆盖什么，智能问数和经营分析怎么协同，知识、Skill、工具怎么分工，这些口径不能散在聊天里。
第三步，建 03_交付物目录与版本计划.md。我需要知道哪些是主控材料，哪些是范式材料，哪些是脚手架和评测材料，哪些只是后续候选附件。Codex 在这一步很像项目秘书，把“想写的东西”变成可管理的交付物。
第四步，做 04_上下文续接包.md。这一步最关键。每次继续会话前，Codex 都能读这个包，知道当前角色、核心判断、已确认口径和下一步提示词。长项目不怕慢，怕断。
第五步，才开始写四份核心交付：范式正文、可复用能力清单、脚手架方案、质量评测与运营优化方法。每份材料都被要求回到同一条主线：业务问题、分析场景、能力链路、复用组件、脚手架、评测运营。
第六步，把正文压缩成 6 页团队评审材料和 PPT。这里 Codex 的作用不是“做漂亮”，而是帮我把复杂材料压成领导和团队能听懂的几个判断。
第七步，用 06_进展与成熟度管理.md 记录材料到什么程度、缺什么案例、哪些问题待评审。项目不是写完就结束，它还要知道自己成熟到哪了。
这套顺序跑下来，我才发现，Codex 最适合做的不是替我想一句大口号，而是把一个会反复变动的方案，压进一组能续接、能评审、能维护的文件里。
长项目最怕上下文断掉
做方案最常见的问题是，今天讨论一个口径，明天又换一个说法。过几天再开新会，前面的判断已经没人记得清楚。
Codex 在这里最有用的动作，是帮我建立“上下文续接包”。它不是普通摘要，而是把当前角色、职责边界、核心口径、覆盖场景、标准能力链路、后续提示词都写进去。下一次继续推进时，不需要从聊天记录里翻半天，先读续接包就能回到现场。
这件事很像给项目做 checkpoint。
模型的上下文窗口会清空，但项目不能跟着清空。真正能续上的，不是对话历史，而是结构化状态。
范式不是口号，是可复用链路
这个专项最后收敛到一条主线：
业务问题 -> 分析场景分类 -> Agent 能力链路 -> 可复用组件 -> 脚手架方案 -> 质量评测与运营优化这条线很关键。它把“我们要做一个 Agent”改成了“我们要从哪个业务问题出发，用什么分析深度，调用哪些能力，怎么复用，怎么评测”。
后来做盈利分析 Agent Skill 模拟验证时，也沿用了这个思路。不是给代表处、地区部、产品线、集团整体各做一个 Skill，而是拆成：
少量 orchestrator skill
+ 中量结构化方法卡
+ 标准 analysis operation
+ 可复用工具
+ 统一质量检查一句话说，就是：Skill 管流程，方法卡管业务分析方法，operation 管动作语义，tool 管执行。
这个拆法比“一个场景一个 Skill”稳。后者短期看起来快，长期会爆炸。场景一多，路由、维护、复用都会变麻烦。
Codex 适合做方案工程化
很多人用大模型写方案，会停在“帮我生成一份文档”。那当然能用，但价值有限。
更好的用法是让 Codex 管住几个东西：
- 边界：什么做，什么不做。
- 口径：关键定义怎么说，以后不乱改。
- 交付物：哪些材料是主控，哪些是附件。
- 版本：当前到什么成熟度，还有哪些待验证。
- 评测：不是只看输出好不好看，而是看口径、数据、分析、结论，以及上线后怎么发现问题、修正问题。
这样做出来的东西，才有机会从一次讨论变成一套可承接方法。
别误会，这不代表 Codex 可以替人决定业务方向。它不能知道真实组织里谁有权、谁买单、哪个数据口径最敏感。这些还是人来拍板。
但它很适合把人的判断写进系统里。
写进去，后面才接得上。