什么时候需要 Agent，什么时候工作流就够了

Agent 并不等于“把所有步骤交给模型”。它适合在任务路径无法完全预先确定时，帮助选择下一步行动。路径已知、规则清楚的任务，常常更适合显式工作流。

先看控制权在哪里，再看需要几次模型调用。一个固定链路里用了三个模型，也未必需要 Agent。

看路径是否需要动态决定

把一段说明提取成字段、校验后入库，步骤通常可以提前写好。程序负责流程，模型只承担其中的文本理解。

如果任务需要根据搜索结果选择下一次查询、根据工具反馈修正计划，动态决策更有价值。ReAct 等研究探索了推理与行动交替的方式，但工程系统还需要权限、状态与停止条件。

不要因为某个任务涉及“思考”，就默认它必须无限循环。固定工作流也可以使用模型做判断，并由程序限制分支。

从失败成本判断边界

建议内容出错和执行外部操作出错，代价不同。模型可以建议一项操作，但建议不代表授权。

对于发消息、修改资源或提交订单等动作，程序应检查当前权限与必要确认。只读操作也要限定资料范围，不能因为它没有写入就无限开放。

把最大步骤数、总时间、预算和允许工具写成程序规则。停止条件应能被执行器强制实施，而不只是写在提示词里。

用一个路由器练习取舍

下面的任务属性由可信应用代码提供，只演示系统如何按任务性质选择执行方式。它不调用模型，也不是完整的 Agent 框架。

def choose_execution(task):
    if task["changes_external_state"]:
        return "approval-required"
    if task["known_steps"]:
        return "workflow"
    return "bounded-agent"

assert choose_execution({
    "changes_external_state": False, "known_steps": True
}) == "workflow"
assert choose_execution({
    "changes_external_state": True, "known_steps": False
}) == "approval-required"
assert choose_execution({
    "changes_external_state": False, "known_steps": False
}) == "bounded-agent"
print("Execution boundaries checked")

真实系统不能让模型自己填写“这次操作没有副作用”并据此免除检查。任务标签、工具权限与授权信息来自可信配置。

保留可以审计的决策

记录任务目标、选中的工具、经过校验的参数、工具结果状态与停止原因。这些信息能帮助解释执行过程，不需要保存或要求模型公开内部思维链。

如果相同工具反复失败，循环应退出或进入明确的恢复分支。不要让模型通过不断换措辞绕开同一个权限错误。

下一步

把你的任务写成一张流程图，标出哪些步骤可确定、哪些需要动态选择。先把已知步骤实现为工作流。

仅给真正不确定的部分增加受限 Agent，再为超时、重复动作与无进展写出停止行为。下一篇进一步定义工具调用的输入与执行契约。