从聊天框到工作流：理解 AI Agent 人机协作的下一次升级
很多人第一次用 Agent，都会天然地把它理解成一个更强的聊天机器人。
你给它一个任务，它在对话框里回复；你发现哪里不对，再追问一句；它继续生成一大段解释；你再指出问题，它又重新开始。
这个模式在问答、翻译、改一段代码时还可以接受。可一旦任务变长，比如“重构一个模块”“审查一批合同”“调研竞品并生成报告”“在老系统里完成一个跨接口改动”，聊天框很快就会暴露出三个问题：
- 过程不可见：你不知道它到底拆了哪些子任务。
- 决策不可审查：你不知道它为什么选了这个方案。
- 状态不可恢复：中途失败、跑偏、被打断以后，很难从正确的位置继续。
所以今天这篇想讲一个判断：
AI Agent 的下一代交互形态，不会只是一个更聪明的聊天框，而会更像一个可审查、可暂停、可恢复、可回滚的工作流审查台。
这不是概念包装，而是 Agent 真正进入复杂工作的基础设施变化。
一、为什么聊天框不适合复杂 Agent
聊天框最大的问题，不是“不能输入自然语言”，而是它把复杂工作压扁成了一条线。
真实任务通常不是一条线，而是一棵工作树。
比如让 Agent 修改一个老项目里的结算逻辑，它可能需要同时做这些事：
- 理解当前需求；
- 找到结算入口；
- 追踪优惠、库存、支付、订单状态之间的依赖；
- 修改代码；
- 补测试；
- 跑验证；
- 分析失败日志；
- 生成变更说明；
- 等待人类确认高风险决策。
这些步骤之间不是简单的“第一步、第二步、第三步”。它们会分支、并行、失败、重试、合并。某个节点可能需要等人确认，另一个节点却可以继续执行。
但聊天框会把所有东西压成：
用户说一句
Agent 回一段
用户再追问
Agent 再回一段
这就像你明明在管理一个 Git 仓库、一个 CI 流水线、一个任务看板，却非要把所有信息都塞进微信聊天记录里。
短期能用，长期一定混乱。
Legora CTO Jacob Lauritzen 在一次关于 Agent 交互的分享里也强调过类似问题：复杂 Agent 工作的瓶颈，已经不只是执行，而是规划、审查、信任和控制。复杂任务更像一个 DAG，而不是一条对话流。
这也是为什么“Agent 需要超越 Chat”这个话题会越来越重要。
二、Agent 的瓶颈正在从“执行”转向“审查”
过去我们担心的是：AI 能不能做。
现在更现实的问题是：AI 做了以后，人类能不能放心地验。
OpenAI 在 Harness Engineering 文章里有一句很适合概括这个变化：Humans steer. Agents execute. 更关键的是，工程团队的主要工作会从亲手写每一行代码，转向设计环境、表达意图、构建反馈回路，让 Agent 能可靠地完成工作。
这句话放到所有复杂 Agent 场景里都成立。
当执行变便宜以后，真正贵的是这些环节：
- 前期如何把任务拆对；
- 中途如何发现 Agent 跑偏；
- 哪些决策必须交给人类；
- 结果如何低成本验证；
- 出错以后如何回滚或从断点继续。
这和传统软件工程很像。
我们不会要求一个开发者把所有工作都写在聊天记录里。我们会让他提交 PR、跑 CI、写变更说明、接受 Code Review、保留 commit 历史。因为复杂协作从来都不是靠“我相信你”完成的，而是靠可见的过程、可审查的差异、可回放的证据完成的。
Agent 也是一样。
一个生产级 Agent 系统，不能只追求“自动完成”，还要回答：
- 它现在执行到哪里了？
- 它为什么做这个判断？
- 它引用了哪些证据？
- 它调用了哪些工具？
- 它改了哪些东西？
- 人类可以在哪些节点介入？
- 失败以后能不能恢复？
如果这些问题没有答案，那么 Agent 越强，风险越大。
三、MCP 和 A2A 解决的是连接，不是协作本身
最近 Agent 生态里有两个高频词：MCP 和 A2A。
MCP 解决的是 Agent 如何连接外部系统。官方文档把它类比成 AI 应用的 USB-C 接口：让 AI 应用可以连接文件、数据库、搜索、工具和工作流。
A2A 解决的是 Agent 之间如何通信。Google 在 2025 年 4 月发布 Agent2Agent 协议，目标是让不同厂商、不同框架里的 Agent 能更标准地发现、通信和协作。
这两个方向都很重要，但它们还不是完整答案。
因为复杂工作不只是“能连接工具”和“能让 Agent 互相说话”。真正难的是：
- 谁负责拆任务？
- 谁记录状态？
- 谁决定暂停？
- 谁判断结果是否可信？
- 谁保留决策依据？
- 谁允许回滚？
- 谁告诉人类现在该看哪里？
换句话说，MCP 像是工具接口，A2A 像是通信协议，但复杂 Agent 还需要一个工作流底座。
这个底座至少要包含：
| 层级 | 作用 |
|---|---|
| Product UI | 不只是聊天框，而是文档、表格、看板、审查队列 |
| Review Log | 记录决策、证据、版本、人工批准和回滚 |
| State | 保存任务状态、断点、进度、环境信息 |
| Harness | 管理计划、工具调用、权限、验证和错误恢复 |
| Protocols | 通过 MCP 连工具，通过 A2A 连其他 Agent |
没有这个底座，Agent 只是会动的模型；有了这个底座，它才开始变成可靠的工作系统。
四、为什么“异步审查”比“实时追问”更适合人机协作
很多 Agent 产品默认把 Human-in-the-loop 做成实时确认：
是否继续？
是否执行？
是否允许？
是否接受？
这看起来安全，实际上很容易把人拖垮。
如果 Agent 每一步都问你，它就不再是代理，而是一个需要你不断喂指令的实习生。你没有省下注意力，只是把写代码、查资料的负担，换成了看弹窗、点确认的负担。
更理想的方式，是非阻塞式的异步协作。
当 Agent 遇到不确定节点时，不一定要立刻停下来等人。它可以先根据当前信息做一个临时决策，继续完成后续低风险步骤，同时把这个决策记录到审查队列里：
决策点：合同终止条款是否标为高风险
Agent 临时判断：标为高风险
依据：公司政策库 + 过去 12 份黄金合同
影响范围：风险清单、最终报告
人工动作：批准 / 修改 / 回滚
这样，人类不需要被每个节点打断，而是可以在自己方便的时候批量审查。
这和代码审查非常像。
你不会在同事写代码的每一行都冲过去问一句“你确定吗”。你会等他提交一个可审查的变更，然后看 diff、看测试、看说明、看风险点。
Agent 也应该这样。
从同步问答升级到异步审查，本质上是把人类从“实时监工”变成“高杠杆 reviewer”。
五、可恢复状态比长上下文更重要
很多人解决 Agent 复杂任务失败的第一反应，是要更长上下文。
长上下文当然有价值，但它不能替代状态管理。
长上下文解决的是“还记不记得”。状态管理解决的是“能不能从正确的位置继续”。
LangGraph 的 durable execution 文档里有一个很工程化的定义：工作流在关键点保存进度，使它可以暂停，并在之后从中断处继续。这对人类介入、长任务、超时、失败恢复都很关键。
这件事放到 Agent 系统里尤其重要。
一个 Agent 执行长任务时，至少要保存：
- 当前目标；
- 已完成节点；
- 未完成节点；
- 每个节点的输入输出；
- 调用过的工具和参数；
- 外部副作用；
- 人类批准记录；
- 失败原因和重试次数；
- 当前产物版本。
没有这些状态，Agent 一旦失败，就只能从头再来，或者靠一段压缩后的聊天摘要继续猜。
这就是很多长任务越聊越差的根源。
真正可靠的 Agent，不应该依赖“它刚好还记得”，而应该依赖“系统明确保存了它做到哪里”。
六、控制和信任是一组二维坐标
很多讨论会把 Agent 的使用方式分成两个极端：
- 完全自动：让它自己做完；
- 完全人工：每一步都确认。
这两个极端都不够。
更好的判断方式，是把任务放到一个二维坐标里：
- X 轴：控制。人类能不能随时引导、暂停、修正、接管。
- Y 轴：信任。这个任务的结果是否容易验证，失败成本是否可控。
不同区域的策略完全不同。
| 类型 | 适合策略 |
|---|---|
| 高信任、低风险 | 可以自动执行，只保留日志 |
| 中信任、中风险 | 先执行，再进入审查队列 |
| 低信任、高风险 | 必须人工批准后执行 |
| 难验证任务 | 先降维成可验证子任务 |
比如代码格式化、补注释、批量改 import，验证成本低，可以交给 Agent 自动完成。
但数据库迁移、生产配置变更、合同条款判断、外部支付调用，就不能只靠一句“相信我”。这些任务必须有审批、回滚、审计和权限边界。
信任不是凭空产生的，它来自可验证性、边界、历史表现和可控风险。
七、从聊天框走向工作流，最小可落地怎么做
你不需要一开始就搭一个庞大的 Agent 平台。
对开发团队来说，可以先从 6 件事做起。
1. 每个任务都生成计划，但计划必须可修改
不要让 Agent 只在聊天里说“我将分三步完成”。
计划应该变成结构化对象：
{
"goal": "修改结算优惠逻辑",
"steps": [
{"id": "S1", "task": "定位结算入口", "risk": "low"},
{"id": "S2", "task": "分析优惠叠加规则", "risk": "medium"},
{"id": "S3", "task": "修改代码并补测试", "risk": "medium"},
{"id": "S4", "task": "确认数据库兼容性", "risk": "high", "requires_review": true}
]
}
人类可以修改计划，Agent 按计划执行，执行过程反过来更新计划。
2. 每个节点保存状态
节点不是一句话，而是一个可审查单元：
{
"step_id": "S4",
"status": "waiting_review",
"input": "检查数据库兼容性",
"output": "发现旧字段 nullable，需要人工确认迁移策略",
"evidence": ["schema.sql", "2025-11-migration.md"],
"decision": "暂停外部写入",
"next_actions": ["approve", "revise", "rollback"]
}
这比聊天摘要可靠得多。
3. 高风险动作必须审批
高风险动作包括：
- 写数据库；
- 调用外部付费 API；
- 删除文件；
- 修改生产配置；
- 合并 PR；
- 对外发送消息；
- 影响法律、财务、合规判断。
这些动作不应该只靠模型自觉，而应该由系统强制拦截。
4. 工具调用必须可回放
每次工具调用至少记录：
- 工具名称；
- 输入参数；
- 输出结果；
- 错误信息；
- 重试次数；
- 耗时；
- 触发它的计划节点。
这不是为了写日志好看，而是为了在出错时能定位：
到底是模型判断错了？
工具返回错了？
参数传错了？
还是外部环境变了？
5. 产物应该进入工作区，而不是留在聊天里
复杂任务的结果不要只是一段聊天回复。
它应该落到具体产物里：
- 代码变更；
- PR；
- 文档；
- 表格；
- 审查清单；
- 决策日志；
- 测试报告；
- 看板卡片。
聊天适合启动任务，不适合承载整个任务。
6. 用评测驱动信任，而不是用感觉判断
你可以给 Agent 建一个最小评测面板：
| 指标 | 含义 |
|---|---|
| 任务完成率 | 是否真的交付目标 |
| 首轮通过率 | 第一次执行是否通过测试或审查 |
| 人工介入次数 | 人类被打断多少次 |
| 回滚次数 | Agent 决策被推翻多少次 |
| 高风险误判数 | 是否越权、误删、误调用 |
| 平均恢复时间 | 失败后多久能继续 |
只有这些指标变好，才说明 Agent 真的更可靠。
八、未来的 Agent 产品会更像“工作区”，不是“聊天页”
如果把前面这些点连起来，会得到一个很清晰的产品方向：
Agent 的入口仍然可以是聊天。
但真正承载工作的地方，会是一个更高带宽的工作区。
这个工作区里应该有：
- 任务树；
- 执行状态；
- 工具调用记录；
- 产物预览；
- 人工审查队列；
- 权限审批；
- 版本差异；
- 回滚按钮；
- 指标面板；
- 知识和规则入口。
聊天负责表达意图，工作流负责完成任务，审查系统负责建立信任。
这才是 Agent 从玩具走向生产力系统的关键一步。
结尾：Agent 不是替你聊天，而是替你推进工作
聊天框让 Agent 变得容易上手，但也限制了它处理复杂任务的上限。
当任务很短、风险很低、结果容易判断时，聊天足够好。
但当任务变长、风险变高、需要多人协作、需要留下证据时，聊天就不够了。我们需要的是一个可审查的异步工作流：
- 任务能拆分；
- 状态能保存；
- 过程能查看；
- 决策能审查；
- 人类能介入；
- 失败能恢复；
- 结果能验证。
未来真正好用的 Agent，不会只是一个回答更好的聊天机器人。
它会更像一个能进入你工作区、理解你的产物、遵守你的流程、接受你的审查，并且能在失败后继续推进工作的协作者。
AI Agent 的终局，不是把人困在聊天框里。
而是把机器的执行力，嵌入到人类已经熟悉、可控、可审查的工作流里。
参考资料
- Anthropic Engineering：Building effective agents
- OpenAI：Harness engineering: leveraging Codex in an agent-first world
- OpenAI：Unrolling the Codex agent loop
- OpenAI：Computer-Using Agent
- Model Context Protocol：What is the Model Context Protocol?
- Google Developers Blog：Announcing the Agent2Agent Protocol
- LangGraph Docs：Durable execution
- LangGraph Docs：Interrupts / human-in-the-loop
- Legora：Workflows
- Taeho Kim reading note：AI Agents Need More Than Chat
