Workflow 与 Agent 的分界

其实在大多数业务系统和需求中，我们并不常常被要求构建一个完整的、具有完全权限的 Agent 工具。更多的情况是，在已有或是正在开发中的业务系统中"嵌入"一段 AI 能力。那么问题来了：嵌进来的这段能力，到底是 workflow，还是 Agent？

一般我们把流程路径由代码预先写好、反馈确定，LLM 只能使用系统包装后暴露给它的有限工具、并按照业务逻辑选择性路由调用的方式，叫做 workflow。

而像 Claude Code、OpenHarness、Pi Agent 那样——拥有通用的代码读写能力，或是对业务系统灵活、无人为限制的访问（这里说的"完整权限"不是 agent 框架里对文件改动、shell 命令的开关控制，而是业务系统向模型开放了多大的面），并由模型自己决定下一步调用什么——叫做 Agent。

但其实按吴恩达的说法，不必在"算不算 Agent"上较真，统一叫 agentic 就好——这两类本来只是同一个东西在业务上的不同演化。实际开发中也很少有人先拍板"这次做 workflow 还是 Agent"再动手，而是跟着业务需求，在二者之间找落点。

举个具体的例子：我们想给淘宝加一个服务用户的 Agent，分析购物车里的商品有没有同款更低价。为这个功能直接给 Agent 代码库的 read/write 权限，未免太兴师动众。更常见的做法是系统先包装出一套业务接口——搜索、比价逻辑——把这些接口以工具列表交给模型，再按固定顺序编排：先搜索，再比价。这样搭出来的"Agent"，一般就叫它 workflow。当然这个需求也有别的实现路径，这里只取最典型的一种。

最佳的实践方式是：默认从 workflow 出发——编排留在代码里，接口收窄到业务需要的最小集；只有当下一步真的无法被规则穷举时，才把那一小段编排权交给模型。一句话说就是：能用编排 workflow 解决的业务，绝不轻易使用 Agent。