小节四：把确定的步骤固定下来，让 Agent 处理需要探索的部分-大赛人网

学到这里，很容易走向另一个极端，“既然 Agent 能动态决策，那以后所有 Workflow 都可以不要了。”

这恰恰是很多 Agent Demo 一进入生产就出问题的原因。

真正靠谱的做法通常是，确定的事情写死，不确定的事情交给 Agent。

我们用一个 Data Analysis Agent 来看。

用户问，“为什么昨天广告收入下降？”

系统里有一批东西是绝对确定的：

校验用户身份
限制查询时间
限制数据库与表
禁止 SELECT *
限制 SQL 类型
设置超时
设置返回行数
记录审计日志

这些事情千万不要让模型每次“思考一下”。

它们应该由 Workflow / Middleware 写死。

但分析方向可以动态：

先查哪个指标？
是否按媒体拆？
是否继续按广告位拆？
需要看请求还是 eCPM？
什么时候证据已经足够？

这些才适合 Agent。

于是系统变成：

图片[1]-小节四：把确定的步骤固定下来，让 Agent 处理需要探索的部分-大赛人网

你会发现，Agent 不是外层全部接管，而是嵌进 Workflow 中负责最有价值的动态决策。

把两者组合起来看，生产系统更像是一条确定性通道包住一个动态循环：

图片[2]-小节四：把确定的步骤固定下来，让 Agent 处理需要探索的部分-大赛人网

身份、参数、安全、格式化和审计都沿固定路径执行；只有“下一步查什么、何时形成结论”进入 Agent 动态区。这样既保留模型依据 Observation 调整动作的能力，也不会让权限、超时或白名单跟着模型一起变化。

Coding Agent 也一样

固定部分：

创建 workspace
限制目录
加载规则
启动 tracing
设置 MAX_STEPS
任务结束后生成 Run Summary

动态部分：

先读哪个文件？
先搜索还是先运行测试？
这个错误更像依赖问题还是配置问题？
修改以后需要验证什么？

一个实用的五问判断法

以后遇到任何任务，不要先问，“能不能上 Agent？”

先问五个问题。

第一问：完整步骤能不能提前列出来？

如果可以，优先 Chain / Workflow。

比如：

读取 CSV → 去重 → 聚合 → 写数据库

没必要 Agent。

第二问：分支虽然多，但规则是否明确？

如果明确，优先 Workflow。

例如：

金额 > 1 万 → 人工审批
否则 → 自动处理

这不是 Agent 的强项。

第三问：下一步是否依赖上一步的语义结果？

如果是，Agent 价值开始出现。

例如，根据错误日志，判断下一步应该查哪个文件。

第四问：候选动作是否很多，很难提前穷举？

如果是，Agent 更值得考虑。

例如 Coding Agent 可选：

read_file
list_files
search_files
run_test
run_python
edit_file

每个工具还有不同参数。

第五问：任务是否允许一定程度的不确定性？

如果答案是否定的，就必须保留强 Workflow 约束。

支付、删库、生产发布、权限变更，都不能让模型直接掌权。

这五个问题并不是给项目机械打分，而是在帮助我们把三类选择快速分开：

图片[3]-小节四：把确定的步骤固定下来，让 Agent 处理需要探索的部分-大赛人网

步骤能列全、规则又清楚时，优先选择确定性方案；语义反馈会改变下一步、候选动作又难穷举时，再考虑把 Agent 放进 Workflow；只要涉及高风险操作，就应先让 Workflow 掌握控制权，Agent 至多负责分析与建议。

把判断框架写成代码

我们甚至可以写一个小工具帮助自己形成习惯：

def recommend_architecture(
    steps_known: bool,
    rules_clear: bool,
    semantic_branching: bool,
    many_possible_actions: bool,
    high_risk: bool,
) -> str:
    if high_risk:
        return (
            "优先 Workflow；如使用 Agent，"
            "只让 Agent 负责分析与建议，高风险动作必须由确定性规则控制。"
        )

    if steps_known and rules_clear and not semantic_branching:
        return "优先 Chain / DAG / Workflow。"

    if semantic_branching and many_possible_actions:
        return "适合考虑 Workflow + Agent。"

    return "先使用简单 Workflow，再评估是否真的需要 Agent。"


if __name__ == "__main__":
    coding_agent = recommend_architecture(
        steps_known=False,
        rules_clear=False,
        semantic_branching=True,
        many_possible_actions=True,
        high_risk=False,
    )

    payment_system = recommend_architecture(
        steps_known=True,
        rules_clear=True,
        semantic_branching=False,
        many_possible_actions=False,
        high_risk=True,
    )

    print("代码修复任务：", coding_agent)
    print("支付系统：", payment_system)

这段代码当然不是一个万能架构决策器。

它真正的价值，是把本节最重要的思考固定下来，不要问“这个项目能不能用 Agent”，而要问“这个项目里哪些决策值得交给 Agent”。

后面学 Flask 服务化、安全控制、Human Approval、Tracing 时，你会不断看到这个原则回来。