AI Agent 基本概念：什么是 Agentic AI

「AI Agent」这个词现在什么都能指，所以先给一个能立刻用的判据。

一句话判据

下一步做什么，是代码决定的，还是模型决定的？

代码决定 → 工作流（workflow）
模型决定 → agent

就这一条。不看它调了几个工具、跑了多少步、用了哪个框架。

Anthropic 的定义和这个一致：workflow 是 LLM 被编排在预先写好的代码路径里；agent 是 LLM 自己指挥流程和工具使用。

为什么这个区分值钱

因为它决定了两件很实际的事。

一、能不能复现。 模型决定路径，意味着同一份输入两次运行可能走出不同的路。而路径不一样，两次结果就没法比较 —— 你没法做 A/B，没法判断改动有没有用。

有一篇论文专门论证这一点，主张用预定的图替代反应式的循环，理由就是可复现性。

二、错误多久被发现。 工作流的每一步你都知道会发生什么；agent 可能在第三步做了个你没预料的决定，而你在第十步才看到后果。

三种常见形状，都还是工作流

形状	长什么样
串联	A 的输出给 B，B 给 C
路由	先分类，再送到对应分支
编排	一个主控拆任务，分给若干子任务

这三种覆盖了绝大多数真实需求，而且它们都是工作流 —— 路径是写死的，造起来也就有章可循。

只有当编排者本身是模型、而且每一轮都能重新决定派谁干什么的时候，才越过那条线。

建议是：能用工作流解决的，别上 agent。 不是因为 agent 不好，是因为它的复杂度成本主要不在代码，在结果不可复现。

agent 的自主性具体在哪

拆开一个最简单的 agent 循环，「自主」只体现在两处：

for turn in range(max_turns):
    msg = model(messages, tools=tool_schemas)
    messages.append(msg)

    if not msg.tool_calls:
        return msg.content          # ← 它自己决定停

    for call in msg.tool_calls:
        out = tools[call.name](**call.args)   # ← 它自己决定用哪个工具
        messages.append(tool_result(call, out))

加粗的两行就是全部。 其余是管道。

顺带破一个误解：模型并不执行工具。它只是输出一段结构化文本说「我想调这个」，执行的是你的代码。所以安全边界完全在你这边 —— 模型说要删文件，删不删是你决定的。

有哪些类型

按自主程度分是最有用的分法：

类型	谁决定	例子
助手式	人问一句，它答一句	聊天、补全
工具型工作流	代码编排，模型填空	文档摘要流水线
单 agent	模型选工具、决定何时停	编码助手
多 agent	多个模型分工，可能互相交接	一个写、一个审

多 agent 唯一无法被「单 agent 多跑几轮」替代的价值，是独立的判断视角 —— 因为让写东西的那个评判自己，它会夸自己。

这不是智力问题，是它没法跳出自己的视角：它脑子里装的是「我为什么这么做」的整套理由，看到的不是结果，是那串说服自己的过程。

边界与代价

**agent 的自主性和可控性是此消彼长的。**这笔账在循环经济学那边还要乘上轮数。

按这条判据，我自己那套东西不是 agent。它有分阶段的流水线、有状态文件、有预算三卡、有拒收门，但每一步跑什么是我的调度器决定的，模型只负责在给定的一步里产出内容。我一开始也想把它叫 agent —— 后来对着这条判据自查，发现「下一步做什么」从头到尾没有一次是模型说了算。这个诚实很有用：因为它是 workflow，我才能拿同一批输入跑两版直接相减；换成 agent，那些数就没法比了。每多给一分自主，就少一分「我知道它会做什么」。这个交换在有些场景划算，在有些场景是灾难 —— 判据是：出错的代价谁承担。

「agent」这个词的含金量正在被稀释。 很多产品把一个带工具的聊天框叫 agent。用上面那个判据一问就清楚了 —— 不必争论，问「下一步谁决定」即可。

这一篇给的是判据，不是完整定义。 学术上还有更细的划分（有没有记忆、有没有规划、能不能自我修正）。但对刚入门的人来说，先把「谁决定下一步」这一条钉死，比记住五种定义有用。