AI Agent 与聊天机器人的核心差异，不是回答比较像人，而是 Agent 能依工作状态选择工具、读取执行结果、修正下一步，最后留下可验收的成果。若系统只产生一段文字，再长、再聪明，仍比较接近聊天助手。
用四个问题判断它是不是 Agent
OpenAI 将 Agent 描述为能代表使用者完成任务的系统：模型管理工作流程、判断何时完成，并使用工具取得资料或采取行动。单轮 LLM 或未让模型控制工作流程的聊天机器人，则不在这个定义内。OpenAI 的 Agent 建置指南也强调，工具与 guardrails 是核心组成，而非附加功能。
评估企业 AI 工具时，可以问四个问题：
| 问题 | 聊天机器人常见结果 | Agent 应有的结果 |
|---|---|---|
| 它知道工作到哪里吗？ | 依赖整串对话猜测 | 读取明确状态与待办 |
| 它能使用真实工具吗？ | 建议你怎么做 | 查资料、执行受允许的动作 |
| 工具失败后会怎样？ | 解释可能原因 | 读错误、修正或交回人类 |
| 完成后留下什么？ | 一段回答 | 文件、程式、查询或可验收纪录 |
因此，「能呼叫 API」还不够。若没有完成条件、状态、权限和错误处理，工具呼叫只是较花俏的聊天。Anthropic 也把 Agent 定义为会自行决定流程与工具使用的模型，同时指出有些偏好或意图只能由人决定；可信任性并不等于完全放手。Anthropic：Trustworthy agents in practice
数据分析最能看出差别
假设使用者问：「上季新客转化率为什么下降？」
聊天型回答可能读入一份 CSV，直接给出「转化率下降 8%，主因是行动版流失」。但真正可验收的分析还有一串问题：新客以注册日还是首购日定义？分母是造访、注册或进入结帐的人？退款是否排除？跨季完成付款算在哪一季？行动版与桌机是否重复计人？
Agent 工作流应把任务拆成可观察的状态：
- 先确认决策问题、时间范围、分母、粒度与排除条件。
- 探索 schema，找出事件表、订单表与 join key。
- 起草可审阅的 Plan，让业务 owner 修正口径。
- 获得授权后执行 SQL，保留查询与验证 checkpoint。
- 交付 Report，列出发现、证据与限制。
「回答」的验收点是文字看起来是否合理；「工作」的验收点则是需求、过程和成果能否被追问。后者需要的不只是模型，还需要一个容纳状态、工具和 artifacts 的工作环境，也就是常说的 Agent harness。
Lantide Data 把 Agent 放进分析工作面
Lantide Data 是 Local-first 桌面 SQL 分析 IDE，内建与工作区整合的 Agent runtime。正式的 Project Analysis 不是让 Agent 在聊天里直接宣布答案，而是形成 Plan → 审阅／批注 → 使用者按 Execute → Report 的流程；取数逻辑以 SQL 分页为主要证据。产品设计可参考系列导读与定位及Agent 分析工作流。
这套设计的优点不是保证 Agent 不犯错，而是让人能在正式执行前检查口径，并在完成后回到 SQL 与 Report 查证。Agent 可以探索 schema、草拟 Plan、建立与执行查询；但正式 Execute 仍是使用者的可观察动作，Report 的业务解读也仍需负责决策的人判断。
它也不是所有任务的最佳答案。只问 SQL 语法、做一次性栏位预览，用聊天或 Lantide 的 Quick Analysis 会更省事；固定 KPI 的长期监控，成熟 BI dashboard 通常更合适。Lantide 的主场是「问题还要厘清，但成果最后会被追问」的分析工作。
结语
判断一个产品是否真是 AI Agent，不要只看它能不能聊天或按按钮；看它是否理解状态、在权限内使用工具、遇错能停下或修正，并留下可验收成果。评估下一个 AI 分析情境时，可先把「最后要验收的 artifact 是什么」写下来，再决定需要聊天助手还是完整 Agent 工作流。