OpenAI 在 9 月 29 日的 DevDay 上扔出一长串发布，占了头条的永远是 Dots 那种「常驻的智能体」。但对真正在搭 agent 的团队来说，更耐用、也更容易被忽略的一件，是 Decisions API（代号 Luna）。它做的事很朴素：你先定义一组允许的回答，模型再从中做分类、路由，或者挑出 agent 的下一步动作。它仍是有限预览，但思路值得拆开看——因为它点的是 agent 工程里一个反复出问题的地方。
把分支决策从自由生成里抽出来
很多 agent 循环最不稳的一步，是「下一步干什么」靠模型自由发挥：同一个分支，这次选对、下次选错，排查起来毫无头绪。Decisions API 的反方向是，你别让模型自由写，而是把候选动作先列好，让它从里面选。输入可以是文本或图像，输出被约束在你定义的集合里。于是「路由到哪个子 agent」「这笔该不该放行」「下一步调用哪个工具」都变成了可复现、可审计的判断，而不是一次性的自由文本。对一个生产系统，能复现和能审计，往往比「更聪明一点」更值钱。
与 Agents API、Bedrock 是三层不同东西
容易混淆的是，DevDay 同时出现了三个名字里都带 agent 的产品。Decisions API 做窄判断：从你给定的答案集里挑一个。Agents API 跑开放任务：多智能体、工具检索、工具调用、上下文压缩都在这层。Bedrock Managed Agents 则把同一套能力封装进 AWS，让执行落在客户自己的云账号里。把三者统称为「agent API」会掩盖真实分工——一个负责在路口选方向，一个负责上路跑长途，一个负责把车开进你家的车库。Decisions API 的价值，正在于它主动退出了「开放生成」的那一层。
一个很贴近生产的例子：你的 agent 接到一笔订单，需要先判断「该走人工审核，还是自动放行」。若让模型自由生成这一步，它会偶尔给出候选之外的动作、或把边界条件说模糊；改成受约束端点后，输出被锁在「人工审核、自动放行、转风控」这几个你审过的选项里，日志也能直接记「本次选了自动放行及原因」。这类「二选一或多选一」的判断，正是 Luna 最顺手的地方。
为什么比模型发布更值得 builder 看
模型发布的热度总在价格和能力上打转，可 agent 真正卡住生产的地方，常常是「该分叉时怎么分叉得稳」。开放生成在分叉决策上天然脆弱：它既能选对也能选飘，且你很难事后说清它为什么这么选。把分叉收口成一个受约束的端点，等于把不确定性从自由文本里抽走，换成一组你事先审过的候选。这与本站此前看过的把工具调用可靠性做成 harness 一等公民的思路一脉相承：约束该长在系统里，而不是长在提示里。Luna 给的是同一道题在「决策节点」上的具体解法。
落到你的 agent 循环里
对正在写 agent 编排的团队，Decisions API 提供的是一个低门槛的落点：先别急着让模型决定走哪条路，把你业务里那几个关键分叉枚举出来，做成受约束的端点。路由、放行、选工具这类「二选一或多选一」的判断，尤其适合先抽出来。它和 Agentforce 360、Presence 这类在平台层做治理的思路并不冲突，而是互补：平台管的是整条链路的可观测与审批，Decisions API 管的是单个决策节点的确定性。当然，它目前仍是有限预览，能否稳定接住真实流量、延迟与成本曲线如何，还要等更广的接入来验证。
一句话：当你的 agent 开始在路口犹豫，与其多写三遍提示词，不如先把这个路口变成一道有标准答案的选择题。