Agent 不止于 Chat：垂直 AI 时代的协作界面重构

基于 Legora CTO Jacob Lauritzen 在 AI Engineer 大会演讲《Agents need more than a chat》的延伸思考。

引言：那个让人崩溃的三十分钟

如果你真正用过一个能跑几十分钟、能调子智能体、能写文件、能反复检索的「复杂 Agent」，那你大概率经历过这样一段时间。

你给它布置了一个任务：研究一下某家公司，按模板起草一份合同，别犯错。它点点头开始干活——先思考几秒，接着读资料、起 sub-agent、做 web search、写中间文件、再起几个 sub-agent、再读、再写。半小时过去，它把一份看上去煞有介事的合同丢回你面前。

你扫了一眼 Clause 3：不对，逻辑反了，对方的违约责任怎么落到我们头上了？你回它一句：「这里写错了，麻烦改一下，顺便参考一下我之前那份合同。」

它回你一句：「You’re absolutely right.」

然后你看到屏幕上闪出那个最让人心碎的词——compaction。上下文要被压缩了。这一刻你就知道：之前那二十多分钟的中间状态、所有它「想明白」的细节、所有它读过的文档摘要，都会被一团模糊的总结替代。它要进入「context rot」状态了。

它继续装模作样地工作。又过了几分钟，新版本合同出来。你想确认一下：是不是只动了 Clause 3？大概率不是。它顺手把别的地方也改了，可能引入了三处新错误。

这就是当下大量长程 Agent 的真实体验：交付物像盲盒，过程像黑箱，迭代成本高得离谱，最后你宁愿自己写。

问题到底出在哪？是模型不够强吗？是 prompt 不够好吗？是 context window 不够大吗？

这些都不是根因。真正的根因是：我们仍然在用 Chat 这种一维、低带宽的界面去驱动一棵高度并行的工作树，让人类的判断只能在「根节点」发力，让 Agent 在大部分关键决策上都在自说自话。

本文围绕 Legora CTO Jacob Lauritzen 在 AI Engineer 大会上分享的一套观点展开，结合垂直 AI 场景里这一年的真实变化，系统讨论几个问题：

• 在「规划 — 执行 — 审阅」这条新的生产流水线上，瓶颈到底转移到了哪里。
• 为什么 Verifier’s Rule 是决定一个任务能否被 AI 接管的关键。
• 如何用「信任 / 控制」这两个坐标，去重新审视你和 Agent 的协作方式。
• 为什么 Skills 比 Planning 重要，为什么 Elicitation 是必经之路。
• 为什么下一代 Agent 的主战场不在聊天窗，而在 Document、Tabular Review 这类高带宽工件上。

如果你正在做 vertical AI、AI Coding、Agentic Engineering，或者只是想搞清楚为什么 Claude Code、Cursor、Devin 这一波产品的 UX 都在悄悄长得越来越像，这篇文章会比较合你口味。

一、垂直 AI 的真问题：端到端完成复杂工作

1.1 从「增强人」到「替代某段流程」

AI 应用的演进，可以粗略画成三个阶段：

1. 增强单点动作：补全、摘要、翻译、改写。AI 只是工具栏里多出来的一个按钮。
2. 增强单个角色：Copilot、写作助手、客服助手。AI 站在某个具体职业的肩膀上做加法。
3. 端到端接管一段流程：研究 + 起草 + 校对 + 形成可交付物。AI 不再只是按钮，而是承担一段「工序」。

垂直 AI 公司——无论是 Legora 这样的 legal tech，还是金融、医疗、运维、研发领域的同类玩家——本质上都在押注第三个阶段：让 Agent 端到端完成越来越复杂的真实工作。

1.2 端到端的难点不在「做」，而在「规划与审阅」

过去几年，大家最大的焦虑是：模型能不能写出可用代码？能不能写出像样的合同？能不能给出合格的分析？

今天，这件事已经不再是核心瓶颈。Sonnet / GPT-5 / Gemini 这种水平的模型，在大多数标准化任务上已经可以做得不错。真正吃时间、吃心智成本的，是另外两件事：

• 任务上游：把模糊需求拆成可执行的工序、写清楚非功能性需求、给出规范和约束。
• 任务下游：审阅这一堆产出。看一个 800 行的 PR、看一份 30 页的合同、看十几个 sub-agent 写下的研究笔记——你愿意花多少时间认真读？

生产工作的「经济结构」正在反转：做事变得越来越便宜，规划和审阅变得越来越贵。

这一点对设计 Agent 产品意味着：

• 你优化的不再只是「让 Agent 跑得更快、做得更多」。
• 你必须同时优化：人怎么把意图喂进去、人怎么把结果看出来。
• 否则你只是在更高的速度上批量制造垃圾。

二、Verifier’s Rule：可验证性才是真正的分水岭

2.1 什么是 Verifier’s Rule

这条经验法则可以这样表述：

一个任务，如果它本身是可解的，并且它的结果易于验证，那么 AI 迟早会把它做好。

看似平平无奇，但只要往里面多走一步，就能看见非常重要的一刀切：「好不好做」 和 「好不好验证」 是两个相互独立的维度。

• 一个任务可能很难做、但极易验证——例如 SAT 求解、数学竞赛题。
• 一个任务可能很容易做、但极难验证——例如写一段「好」合同、写一篇「好」创意文案。

而 RL、post-training、Agent loop 这些手段的共同前提，恰恰是：得有人或有规则能告诉它「你这次干对了没」。没有 verifier，没有训练信号；没有训练信号，靠运气堆 prompt 是堆不出可靠 Agent 的。

2.2 同一个领域内，任务也是「一字铺开」

不能笼统地说「legal 难」或「coding 容易」。同一个行业里，不同任务在「可验证性」维度上拉得非常开。以法律为例：

类似的拆解可以套到几乎所有行业上。

• 金融：财报数据抓取、勾稽校验 —— 极易验证；投资判断 —— 不可验证。
• 运维：日志匹配规则、巡检脚本运行结果 —— 极易验证；架构演进方向 —— 不可验证。
• 代码：单元测试可覆盖的 bug 修复 —— 易验证；「做一个成功的 C 端产品」 —— 几乎不可验证。

做垂直 AI 产品的第一件事，应该是把目标行业里所有典型任务，按「易解 / 易验证」这张二维图铺一遍，看清楚哪些任务今天就能压榨干净，哪些任务再等三年也别指望端到端自动化。

2.3 别试图「硬刚」不可验证任务

面对不可验证的任务，常见的两个错误姿势：

1. 加更多模型、加更多 RAG、加更多 tool：你只是在不可验证的空间里更快地生产更难复核的结果。
2. 让 Agent 自我评审：让另一个同样不可验证空间里的 Agent 给前一个打分。结果是两层不可验证叠加，幻觉只会更精致。

正确姿势是下一章的核心：改造任务的形态，把它从「不可验证」一步步搬到「可验证」那一侧。

三、协作的两个坐标轴：信任与控制

要让 Agent 真正胜任复杂工作，必须同时回答两个问题：

• 我有多相信它独立完成？(Trust)
• 我有多容易把我的判断注入它的工作？(Control)

这两个维度是正交的，缺一不可。

3.1 Trust：我多大程度上不用看你的过程

Trust 决定了审阅成本。

• Trust 低：你必须看每一条 trace、每一次 tool call、每一份中间产物。Agent 跑得再快，你也得花成倍的时间复核。
• Trust 高：你只看最终交付物，甚至直接采用。

现实里，Trust 不是「感觉」，而是被任务的可验证性、Agent 的工具范围、历史成功率共同决定的。可验证性越强、动作空间越收敛、过往证据越多，Trust 越高。

3.2 Control：我多大程度上可以把判断喂进去

Control 决定了结果的方向感。

• Control 低：你只能在最开始下达一个目标，中间它干什么你不知道，你也插不上嘴。
• Control 高：你可以在任何关键节点表达偏好、否决方案、追加约束。

Chat-only 的 Agent 几乎注定低 Control —— 因为你只能在「开头」和「末尾」两个点切入对话，对中间无数关键的小决策无能为力。

3.3 不同任务落在不同象限

把 Trust 当作 Y 轴、把 Control 当作 X 轴，所有任务都可以找到自己的位置：

• 高信任 + 低控制需求：例如格式化、定义检查、批量翻译。让它跑就好。
• 高信任 + 高控制需求：例如多轮的研究 / 起草任务。Agent 能干活，但你需要在关键节点持续注入判断。
• 低信任 + 任意控制需求：例如战略性决策、敏感外发内容。这里不该由 Agent 主导，最多让它做 research 助手。

做产品时最容易踩的坑是：把第二象限的任务，用第一象限的 UX 去做。一个需要持续控制的任务，被塞进一个只允许「扔过去 → 等结果」的聊天框，体验崩溃几乎是必然的。

四、如何系统性地提升 Trust

Trust 不是「多用一阵子就有了」，它是可以被工程化提升的。有三种相互配合的手段。

4.1 把任务往「可验证」的一端拖

这是 verifier’s rule 在工程上的直接推论。任务本身不可验证不要紧，可以通过改造任务边界来让它变得可验证。

几个例子：

• 代码任务：给 Agent 浏览器访问权限 + 强制 TDD。本来「写一个能跑通的功能」是软指标，加上「跑通这套测试用例 + UI 操作脚本通过」之后，立刻变成硬指标。
• 合同起草：原任务「写一份好的并购协议」不可验证。换一种思路：让 Agent 输出新合同后，与历史上经过法庭、经过谈判验证过的golden contracts做相似度比对，作为验证代理（proxy verifier）。语义上不一定 100% 对，但是工程上立刻有了反馈信号。
• 数据分析：让模型自己解释结论很难验证，但让它生成可执行的 SQL/Python 代码片段，再用确定性方式比对预期数据形状、行数、汇总值，可以把「分析对不对」近似为「代码跑得过不过」。

这一类技巧的核心叫做proxy verification：找不到完美的真理，那就找一个相关性足够高、可机器判定的代理指标。

4.2 任务分解：把整块工作拆成可验证的小块

「写一份合同」当作一个整体不好验证，但它可以拆成一棵子任务树：

• 选风险偏好（Risk profile）——人决策。
• 选模板/先例文档（Precedent documents）——人决策。
• 选谈判立场（Negotiation stance）——人决策。
• 拉骨架（Skeleton）——Agent，可验证：结构匹配模板。
• 填充条款 ——Agent，部分可验证：定义一致性、引用编号、术语表。
• 排版与格式 ——Agent，可验证：与公司既有合同视觉一致。
• 定义检查（Linting）——Agent，可验证：每个定义都被用过、每个被用术语都被定义。

分解之后你会发现：

• 真正需要人类判断的，只剩下少数几个「非功能性」的节点。
• 大量易验证的节点可以放心交给 Agent，它在 loop 里反复改、反复跑 verifier，最终趋向稳定。

这是垂直 AI 工程师真正该花时间的地方：不是发明更聪明的 prompt，而是发明更精细的任务结构。

4.3 Guardrails：通过限制动作空间换取信任

Guardrails 是另一条提升信任的途径——通过收缩 Agent 的能力边界，让「最坏情况」变得可承受。

常见做法：

• 只允许编辑指定的几个文件、指定的目录。
• 只允许访问白名单内的网站。
• 危险动作（删数据库、付钱、发邮件）必须二次确认。
• 一段时间 / 一定 token 内的最大调用次数硬封顶。

Claude Code 是一个非常直观的样本：

• 在低信任模式下，每个 shell 命令都要问一遍「要不要执行？」——理论上最安全，实际上工作流被打断到几乎不可用。
• 在 「YOLO 模式」 下，它什么都敢干——但凡你忘了挂分支、忘了 docker 化、忘了快照，它确实可能把你的 prod 数据库一并送走。

现实里的优雅解法不是二选一，而是按任务危险等级 × 工作目录可逆性配置不同程度的 guardrails。例如：

• 在沙箱 git worktree 里完全放手。
• 在主仓库只允许读、不允许直接 push。
• 任何会触及外网 / 数据库 / 支付 / 用户通知的动作，强制人审。

Guardrails 不会让 Agent 更聪明，但是会让你敢于让它跑久一点。这一点比聪明更重要。

五、如何系统性地提升 Control

Control 是这套理论里最容易被低估、也最容易被错误实现的一环。

复杂 Agent 工作可以画成一个有向无环图（DAG）——或者更简单地，一棵工作树。例如「为一组员工合同写一份合规报告」这个任务大致是这样的：

撰写报告 ├─ 研究组织背景 │ ├─ 检索公司公开信息 │ └─ 检索过往内部文档 ├─ 审阅每一份合同 │ ├─ 检查 IP 条款 │ ├─ 检查保密条款 │ ├─ 检查竞业条款 │ └─ 检查终止条款 ├─ 汇总风险点 └─ 出具最终报告

问题在于：人类的判断在哪些节点能介入？

根据介入位置不同，Control 等级也完全不同。

5.1 朴素方案：只在根节点说话

你扔出一句「给我写份报告」，半小时后看到结果。中间所有分支它都自己决定。

• 你说「看 IP 条款」，它可能去看保密条款。
• 你说「重点关注美国法」，它可能下沉到欧盟法。
• 你说「别太长」，它可能交给你 30 页。

这种模式下，控制基本为零。开篇那个让人崩溃的三十分钟，就是这个模式。

5.2 Planning：开头先对齐一次

Planning 模式是当下市面上最常见的「Control 增强」：

• Agent 拿到目标后，先输出一份计划：第一步做什么、第二步做什么、用什么工具、产出什么。
• 你看一眼，提一些修改，然后说「开干」。
• 它按计划走完整棵树。

相比朴素方案，Planning 把一次「根节点对齐」做得更扎实，确实有用。Claude Code 的/plan、Cursor 的某些模式、各种 deep research 类产品，本质上都在用这个思路。

但是 Planning 有几个非常硬的天花板：

1. 要做 plan，本身就得先把任务想明白一半。你不做点 research，根本写不出靠谱的计划。
2. Plan 的颗粒度永远小于真实工作的颗粒度。某份合同里突然出现的「特殊条款 X」，你在 plan 阶段根本无从知晓。
3. Plan 是静态的。一旦开始执行，遇到出乎意料的情况，它要么强行套 plan、要么悄悄改 plan，你都不知道。
4. Plan 阶段往往要回答一堆你也答不上的问题。Agent 没真正干活，你也没真正干活，两个人盯着一张 outline 互相试探。

打个比方：Planning 模式像一个同事进你办公室、说一遍他打算怎么做、你点点头，然后他消失三十分钟，回来塞给你一份完成品。中间没有任何机会调整方向。这不是一种健康的协作方式。

Planning 不会消失，但它绝不应该是 Agent 协作的主轴。

5.3 Skills：把判断编码进每一个节点

Skills 是当前最被低估的一种 Control 机制，也是 Claude Code、Cursor、各类企业 Agent 平台正在快速收敛的方向。

一个 Skill 本质上是一份针对某种节点的写死方案：当 Agent 在工作树中遇到「审阅终止条款」这种节点时，它不再凭感觉，而是按预先准备好的 skill 执行。一个典型的 skill 可能包含：

• 触发条件：在做合同审阅、且当前条款类型是 termination。
• 行动步骤：先抽取双方权利义务、再比对 golden clause、再生成风险评级。
• 异常分支：如果合同适用法是 EU 成员国法，额外执行 GDPR 终止合规检查。
• 输出 schema：固定字段、固定 markdown 格式、固定 risk level 枚举。

Skills 模式相对 Planning 有三个本质性的优势：

1. 判断粒度从「整体任务」 下降到了 「节点」。你不必在开始时穷举所有情况，而是把多年沉淀的「某类情况怎么处理」一次性写好，未来所有任务自动复用。
2. 支持 contingency。Planning 阶段不知道有没有 EU 合同；Skills 阶段，碰到再触发就行。
3. 支持渐进披露（progressive discovery）。Agent 在执行过程中才发现的细节，可以匹配上对应的 skill，绝不丢。

如果说 Planning 是一次性 alignment，Skills 就是长期可复用的组织记忆。垂直 AI 公司的护城河，本质上就是「多少业务知识沉淀进了 skills」——这是单纯换基础模型换不掉的资产。

5.4 Elicitation：让 Agent 主动来找你

Skills 再丰富，也会有空白地带。真实复杂任务里，永远会遇到「没人写过 skill」、「几个 skill 之间冲突」、「信息不充分」的情况。

这时候，更合理的姿势是Elicitation——Agent 主动停下来问人。

但 Elicitation 不是「随时弹窗骚扰你」这么粗暴。一个工程上比较成熟的实现包括：

1. 能继续就继续，不要无谓阻塞。Agent 遇到不确定时，先按一个合理的默认值继续往下推进。
2. 写决策日志（Decision Log）。所有由 Agent 自行做出的、本应该由人决策的选择，都写入一份结构化日志：时间、节点、可选方案、采用方案、理由。
3. 批量异步审阅。人在合适的时间点回到决策日志，要么 approve、要么 reverse。反转决策时，Agent 自动重跑相关分支。
4. 真正必须停下来的情况，才向人发出 question：例如安全、合规、付费、用户外发、不可逆动作。

这套模式带来的体验是：

• 工作不停。人不需要 7x24 守着 Agent。
• 控制不丢。人随时可以倒回去看决策、改决策。
• 重要的事，仍然由人拍板。

这才是「高带宽 + 高 Control」 的真正含义：人不是去陪 Agent 一句一句聊，而是去检阅一份结构化的决策清单。

六、为什么 Chat 撑不起复杂 Agent

现在可以回到开篇那个三十分钟的失败案例。它的根本问题，其实可以一句话概括：用一维通道驱动一棵高度并行的工作树。

Chat 作为协作界面有几个无法克服的硬伤：

1. 线性：消息一条一条往下排，你看见的永远是「最近一句」。一棵工作树根本没法塞进这种结构。
2. 低带宽：你只能用一段文字描述意图、用一段文字接收结果，所有结构信息都被压成 token 序列。
3. 上下文易腐烂：长对话必然触发 compaction / summarization，中间状态被压缩，细节被丢弃。
4. 审阅成本极高：让你在一段 30 屏长的对话里找出哪里改对了、哪里改错了，几乎不可能。
5. 无法精准定位：你很难指着对话里的某一段说「只改这里、别动其他」。

更糟的是，Chat 给人一种错觉：好像所有事情都能在一个聊天框里搞定。这种错觉让 Agent 产品在早期看起来很惊艳，到了真实复杂任务里就原形毕露。

要厘清的一点是：Chat 作为输入手段非常优秀。

• 自然语言是最通用的指令接口。
• 表达模糊意图、追加约束、随时换方向都很灵活。
• 它适合「启动一个任务」、「追加一条要求」。

Chat 真正不适合的是做主协作界面。它适合发指令，不适合一起干活。一旦工作进入「需要持续高 Control + 持续审阅」的状态，必须切换到别的界面。

七、协作界面的未来：高带宽工件

那「别的界面」是什么？

它的统一抽象是：高带宽工件（high-bandwidth artifacts）。

一个合格的协作工件具备以下几个特征：

• 持久化：不是消息流，而是一个长期存在的实体，可以被多次回到、反复修改。
• 结构化：内部有清晰的层级、区域、字段，可以精确定位「这里」。
• 多人/多 Agent 可标注：可以打高亮、加评论、@ 协作者或 sub-agent。
• 可与具体任务原语对应：例如「一份文档」、「一张表」、「一棵审阅树」、「一组测试结果」。

不同行业的工件长得完全不一样，但抽象是一致的。Legora 给出了两个非常具体的例子。

7.1 Document：天然适合人与 Agent 共同生长

文档是法律、咨询、研究、内容行业里最自然的协作单位。

它在 Agent 协作场景下有几个非常好的性质：

• 天生支持精确定位：你可以选中第 3 条 clause，告诉 Agent「只改这里」，而不必让它扫整篇。
• 天生支持评论与讨论：你可以在某段旁边加一条评论、@ 一个专门做 IP 审查的 sub-agent。
• 天生支持分段交接：可以把不同段落交给不同的 Agent 处理，像把章节分给不同的同事。
• 天生有版本与 diff：每一次修改都可视化，谁动了什么一目了然。

对比 Chat：你想在聊天框里完成上面任何一件事，都会变得极其别扭。

7.2 Tabular Review：让审阅变成「扫表」

第二个被 Legora 推上前台的工件，是表格化审阅（Tabular Review）。

场景大致是这样：你需要审一批合同，关注若干维度——比如终止条款、保密条款、IP 归属、争议解决方式。传统做法是 Agent 写一份冗长报告，把所有合同都罗列一遍。表格化审阅则把这件事变成：

• 每一行：一份合同。
• 每一列：一个审阅维度。
• 每个单元格：Agent 的判断 + 引用 + 风险标签。
• 关键标记：Agent 主动 flag 出它「不确定」或「认为风险高」的格子。

这个界面下的体验完全不同：

• 你扫一眼标红的格子，就知道注意力该花在哪。
• 点开任意一格，能看到原文引用与 Agent 的推理路径。
• 在某一格改判定，Agent 自动重新生成下游汇总和报告。
• 高频复用：把同样的列定义复用到下一批合同，整个审阅流程瞬时复刻。

本质上这是把审阅这件事的形态，从「读长文档」改成「扫一张结构化表」。审阅成本被一次性砍掉一个量级。

7.3 把它泛化到所有行业

这个抽象不是法律专属。换一个行业，工件就换一种长相：

• 代码工程：Document = 源码文件、ADR、设计文档；Tabular Review = PR 列表、测试矩阵、依赖升级表。
• 运维：Document = SOP、值班交接、事故复盘；Tabular Review = 工单分类表、巡检结果矩阵、资产清单。
• 金融分析：Document = 研报、备忘录；Tabular Review = 公司对比表、估值表、风险因子表。
• 销售/CRM：Document = 客户档案、提案；Tabular Review = pipeline 表、客户健康度矩阵。

做垂直 AI 产品的一个核心动作，就是回答这两个问题：

• 我所在的行业，最自然的「工件」是什么？
• 怎样让 Agent 在这种工件上和人一起工作，而不是在聊天框里一来一回？

谁先答好这两个问题，谁就先把 Agent 从「玩具」变成「同事」。

7.4 UI 正在悄悄收敛

如果你最近半年密切关注 AI 工具，会发现一种悄悄的收敛：

• 聊天框还在，但是被推到侧边或底部。
• 主舞台变成了文档、画布、表格、看板、IDE、流程图。
• 任何一个长任务，最终都会以一个或多个可持久化的工件作为承载。
• 进度、变更、决策被结构化展示，不再是一长串气泡。

这不是某个团队的设计偏好，而是一个被任务本身倒逼出来的结构。一旦你认真做端到端复杂工作，Chat-only 就是死路一条。

八、给工程师的实践清单

把前面这些观点压成一份可执行的清单，便于落地到自己的项目里。

8.1 在「任务一字铺开」上花一天

• 列出目标行业 / 团队里最高频的 30 个任务。
• 给每个任务打两个分：易解性、易验证性，1~5 分。
• 画到二维图上，圈出三类区域：
  • 高解 + 高验证：第一批彻底 Agent 化的目标。
  • 高解 + 低验证：花精力构造 proxy verifier、做任务分解。
  • 低解 + 低验证：今天先别碰，AI 只做信息助手。

8.2 给关键任务画工作树

• 选 1~2 个高优先级任务，画出它真实的 DAG，而不是脑补的「三步走」。
• 标出哪些节点是「人决策」、哪些节点是「机器可验证」、哪些节点是「灰色地带」。
• 灰色地带是 Skills 和 Elicitation 的主战场。

8.3 一次性投资 Skills，而不是迭代 Prompt

• 拒绝「再调一版 system prompt」式的短期优化。
• 把团队里资深成员的判断，结构化为一组 skills：触发条件、动作步骤、异常分支、输出 schema。
• Skills 应该有版本号、有 owner、有变更评审，像对待生产代码一样对待。

8.4 给 Agent 装 Decision Log

• 任何 Agent 替人做出的「本应人决策」选择，必须落进结构化日志。
• 日志条目至少包含：时间、节点、可选方案、采用方案、置信度、可被 reverse 的范围。
• 提供一个独立的审阅 UI，让人能一次性扫掉一批决策。

8.5 用 Guardrails 换取「敢让它跑久」

• 区分沙箱环境和生产环境，给前者最大自由度，给后者严格白名单。
• 任何不可逆动作必须经过一道显式人审。
• 制定 Agent 行动的「单次预算」（token、时间、调用次数），到顶强制暂停。

8.6 把 Chat 退回到「输入端」

• 不要把 Chat 设计成主协作界面。
• 用 Chat 启动任务、追加约束、做模糊解释。
• 用 Document / Tabular / Canvas / IDE 这类工件承担协作和审阅。

8.7 把语音、白板、图形当作 Agent 的真正接口

人和人之间被语言绑架是因为生理限制——你画不出脑子里的组织架构图，只能用嘴说。Agent 没有这个限制。

• 给 Agent 提供结构化输入：JSON schema、表格、流程图、文件树。
• 给 Agent 提供结构化输出：让它写到表格里、画到图里、写到代码块里，而不是塞回聊天框。
• 把 Agent 当作一种新型 IO 设备，而不是「一个会打字的同事」。

九、写在最后：不要把 Agent 困在人类语言里

最容易被忽视的一句话其实是：Agent 不是人，不要把它困在人类语言的低带宽通道里。

人和人协作之所以围着 Chat 和会议转，是因为我们之间只有这一根细管子可用——你脑子里那张组织架构图、那张系统拓扑、那张风险矩阵，都必须先翻译成一段段话，再被对方在脑子里重新拼回去。这是生理上的妥协。

但 Agent 不需要妥协。

• 你可以直接把组织架构图喂给它。
• 你可以直接把数据库 schema 摆在它面前。
• 你可以让它在表格、文档、画布、代码上原地协作。
• 你可以让它把决策、风险、建议结构化吐出，而不是堆成一段散文。

下一代真正强大的 Agent 产品，不会比谁的聊天框「更聪明」，而会比谁敢于跳出聊天框、敢于在更高维的工件上和人一起工作。

Verifier’s Rule、Trust × Control、Skills、Elicitation、高带宽工件——这一整套概念其实指向同一句话：

让人继续做只有人能做的事，让 Agent 做所有可以被验证的事，让两者在一个真正适合协作的界面上汇合。

开篇那个让人崩溃的三十分钟之所以存在，是因为我们仍然在用上一代界面驱动这一代 Agent。当协作界面跟上来，那段三十分钟会变成几次明确的决策点、几张被点亮的表格、几段被高亮的文档——而不是一长串「You’re absolutely right」。

这才是 Agent 工程真正值得花十年的方向。