Agent 经常被描述为“能够自主完成任务的 AI”。从工程角度看，它是一种运行循环：观察当前状态，让模型选择下一步动作，执行工具，把结果放回状态，再决定继续还是结束。

目标 → 观察 → 选择动作 → 调用工具 → 获得结果
              ↑                    ↓
              └──── 继续或结束 ────┘

这种结构适合路径无法提前完全确定的任务，也意味着结果、成本和执行时间更难预测。

固定流程优先

如果任务始终按照相同步骤完成，例如读取表单、校验字段、查询接口、生成通知，就应该使用 Workflow。分支可以由明确条件控制，每一步都容易测试和审计。

如果任务是“调查某个主题并根据发现继续查证”，不同问题可能需要不同来源和工具顺序，此时 Agent 才有价值。模型可以先搜索，再根据结果决定读取哪篇资料，发现缺口后继续查询。

Agent 的四个基本组成

一个最小 Agent 包含：目标、模型、工具和运行状态。目标说明完成标准，模型选择动作，工具连接环境，状态保存已经观察到的结果和剩余任务。外层运行器还需要最大迭代、超时、权限和停止条件。

缺少任何一项都会产生问题：目标模糊导致不断探索，工具描述含糊导致选错动作，状态过长导致模型忽略关键结果，没有停止条件则可能重复调用。

自主性是范围，不是开关

可以让 Agent 只决定查询顺序，最终写操作仍由固定流程完成；也可以让模型生成计划，但由人选择是否执行。并不是只有“完全自动”和“完全手工”两种选择。

更稳妥的路径是逐步增加自主性：先做只读研究助手，再允许创建草稿，最后才考虑经过确认的外部动作。每增加一项能力，都补充权限、失败处理和测试。

一个简单判断法

把任务画成流程图。如果大多数分支可以由业务规则提前写出，就用 Workflow；如果下一步必须阅读当前结果后才能决定，并且可用动作集合有限，考虑 Agent；如果连目标和成功标准都说不清，先澄清需求，不要用 Agent 掩盖问题。

Agent 不是比 Workflow 更高级的答案。它用可预测性换取适应性，只有这种交换对当前任务有价值时才值得使用。