做 Agent 的人几乎都卡在同一个纠结上：AI 和程序，到底几几开？
AI 用多了，结果飘忽，同样的输入两次不一样，出了事没法复现，心里没底。程序写多了，流程是稳了，可需求一变就得改代码，一堆 if-else 永远补不完，灵活性荡然无存。于是很多人把它想象成一个滑块：往左靠可控，往右靠灵活，然后痛苦地在中间找一个点。
这个问法本身就错了。AI 和程序不是一个滑块，你不是在定一个全局比例。
别定比例，逐点分配
真正在设计里做决定的时候，你面对的从来不是”整个系统 AI 占几成”，而是一个个具体的步骤：这一步要不要 AI？那一步能不能写死？
所以问题不是”几几开”，而是这一步的不确定性，该由谁来承担。
把它拆开看，一个系统里其实有两类活儿：
1 | |
判断这类活，输入空间是开放的，规则永远写不全，交给程序就是自讨苦吃；执行这类活，要的是确定、可复现、可回滚，交给 AI 就是自找麻烦。
一句话：AI 负责想，程序负责做和守。AI 提议，程序把关。最后”比例”是多少，是这么一步步分出来的结果，不是你一开始拍脑袋定的目标。
“不可控”的真解：可控来自边界，不是来自少用 AI
觉得 AI 不可控，于是少用 AI，这是把因果搞反了。
AI 的不可控，不是因为你用得多，而是因为你让它的输出直接落地了。让模型自由吐一段文本，然后拿这段文本去改数据库、去调外部接口，那当然不可控。
正确的做法是给 AI 的输出加一道收口：
- 让它输出结构化的 JSON，而不是自由文本；
- 用 schema 校验，不合格就打回重来；
- 能调用的工具、能操作的对象，走白名单；
- 关键动作可回滚、全程可观测。
这就像给 AI 圈一个围栏。围栏是程序，围栏里 AI 尽情发挥。它可以天马行空地想，但想出来的东西要出栏、要产生真实影响，得先过程序这道闸门。
所以可控性来自边界，不来自比例。你不需要少用 AI，你需要给 AI 划好安全边界。边界清楚了，AI 用得再多也不慌。
“不灵活”的真解：灵活来自识别变化点，不是来自多用 AI
反过来，觉得程序不灵活就无脑堆 AI，同样是搞反了。
程序不灵活，不是因为它是程序，而是因为你把本来会变的东西也写死了。
改进的关键是先分清楚：到底什么在变？
- 变的是判断逻辑（怎么理解意图、怎么分类），那就交给 AI 或提到 prompt、配置里；
- 变的是流程编排（步骤顺序、分支条件），那就做成可配置的 DAG，而不是写死的函数调用链；
- 真正几乎不变、而且错了代价很高的那一小部分，才值得硬编码。
灵活不是靠 AI 占比高换来的，是靠你把”变化点”识别出来、单独抽出去换来的。变化点交给容易改的东西（AI、prompt、配置），稳定点留给程序。
一个能落地的选择法：对每一步问四句话
具体到每一个步骤，不用玄学，问这四句话就够了：
1 | |
四个答案叠起来，这一步归 AI 还是归程序，基本就清楚了。整个系统的”比例”，就是把每一步这么问一遍之后自然浮现出来的。
三种最常用的组合
真实系统里，AI 和程序很少是并列的两块，更多是嵌套配合：
- AI 决策，程序执行：模型选该调哪个工具、传什么参数，程序负责真正去跑、去处理副作用。
- 程序编排，AI 填空：流程骨架是固定的 DAG，每个节点内部才用 AI 做判断——这正是 workflow 类框架的思路。
- AI 生成，程序校验：模型先生成，程序校验，不通过就带着错误信息让它重试。
拿一个研发自动化 Agent 举例：需求理解、代码意图这些判断交给 AI；执行 git、编译、跑测试、卡发布门禁这些执行交给程序；失败诊断则是 AI 提议修复方案、程序执行并再验证一遍。判断和执行各归各位，谁也不越界。
收尾
回到最初那个纠结：AI 和程序几几开？
答案是——别问几几开。比例是结果，不是目标。
设计的时候，逐步去问”这一步的不确定性归谁”，让 AI 提议、程序把关。可控来自边界，灵活来自识别变化点。真正健康的系统，往往是程序的骨架，加上 AI 的关节：骨架撑住确定性，关节负责应对模糊和变化。
比例自己会长出来，你只要把每一步放对位置。