文章目录
- 引言：那个让人崩溃的三十分钟
- 一、垂直 AI 的真问题：端到端完成复杂工作
- 1.1 从「增强人」到「替代某段流程」
- 1.2 端到端的难点不在「做」，而在「规划与审阅」
- 二、Verifier's Rule：可验证性才是真正的分水岭
- 2.1 什么是 Verifier's Rule
- 2.2 同一个领域内，任务也是「一字铺开」
- 2.3 别试图「硬刚」不可验证任务
- 三、协作的两个坐标轴：信任与控制
- 3.1 Trust：我多大程度上不用看你的过程
- 3.2 Control：我多大程度上可以把判断喂进去
- 3.3 不同任务落在不同象限
- 四、如何系统性地提升 Trust
- 4.1 把任务往「可验证」的一端拖
- 4.2 任务分解：把整块工作拆成可验证的小块
- 4.3 Guardrails：通过限制动作空间换取信任
- 五、如何系统性地提升 Control
- 5.1 朴素方案：只在根节点说话
- 5.2 Planning：开头先对齐一次
- 5.3 Skills：把判断编码进每一个节点
- 5.4 Elicitation：让 Agent 主动来找你
- 六、为什么 Chat 撑不起复杂 Agent
- 七、协作界面的未来：高带宽工件
- 7.1 Document：天然适合人与 Agent 共同生长
- 7.2 Tabular Review：让审阅变成「扫表」
- 7.3 把它泛化到所有行业
- 7.4 UI 正在悄悄收敛
- 八、给工程师的实践清单
- 8.1 在「任务一字铺开」上花一天
- 8.2 给关键任务画工作树
- 8.3 一次性投资 Skills，而不是迭代 Prompt
- 8.4 给 Agent 装 Decision Log
- 8.5 用 Guardrails 换取「敢让它跑久」
- 8.6 把 Chat 退回到「输入端」
- 8.7 把语音、白板、图形当作 Agent 的真正接口
- 九、写在最后：不要把 Agent 困在人类语言里
基于 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 应用的演进，可以粗略画成三个阶段：
- 增强单点动作：补全、摘要、翻译、改写。AI 只是工具栏里多出来的一个按钮。
- 增强单个角色：Copilot、写作助手、客服助手。AI 站在某个具体职业的肩膀上做加法。
- 端到端接管一段流程：研究 + 起草 + 校对 + 形成可交付物。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 容易」。同一个行业里，不同任务在「可验证性」维度上拉得非常开。以法律为例：
| 任务类型 | 易解性 | 易验证性 | 当下 AI 的相对位置 |
|---|---|---|---|
| 合同中定义检查（每个被使用的术语是否都定义过、是否有死定义） | 高 | 高 | 可完全交给 Agent |
| 合同条款格式统一、引用编号一致 | 高 | 高 | 可完全交给 Agent |
| 起草一份新合同条款 | 高 | 低（要打官司才知道扛不扛得住） | 需要人深度参与 |
| 诉讼策略（litigation strategy） | 低 | 极低（五个律师五个答案） | AI 只能做信息整理，不做决策 |
类似的拆解可以套到几乎所有行业上。
- 金融：财报数据抓取、勾稽校验 —— 极易验证；投资判断 —— 不可验证。
- 运维：日志匹配规则、巡检脚本运行结果 —— 极易验证；架构演进方向 —— 不可验证。
- 代码：单元测试可覆盖的 bug 修复 —— 易验证；「做一个成功的 C 端产品」 —— 几乎不可验证。
做垂直 AI 产品的第一件事，应该是把目标行业里所有典型任务，按「易解 / 易验证」这张二维图铺一遍，看清楚哪些任务今天就能压榨干净，哪些任务再等三年也别指望端到端自动化。
2.3 别试图「硬刚」不可验证任务
面对不可验证的任务，常见的两个错误姿势：
- 加更多模型、加更多 RAG、加更多 tool：你只是在不可验证的空间里更快地生产更难复核的结果。
- 让 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 有几个非常硬的天花板：
- 要做 plan，本身就得先把任务想明白一半。你不做点 research，根本写不出靠谱的计划。
- Plan 的颗粒度永远小于真实工作的颗粒度。某份合同里突然出现的「特殊条款 X」，你在 plan 阶段根本无从知晓。
- Plan 是静态的。一旦开始执行，遇到出乎意料的情况，它要么强行套 plan、要么悄悄改 plan，你都不知道。
- 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 有三个本质性的优势：
- 判断粒度从「整体任务」 下降到了 「节点」。你不必在开始时穷举所有情况，而是把多年沉淀的「某类情况怎么处理」一次性写好，未来所有任务自动复用。
- 支持 contingency。Planning 阶段不知道有没有 EU 合同；Skills 阶段，碰到再触发就行。
- 支持渐进披露（progressive discovery）。Agent 在执行过程中才发现的细节，可以匹配上对应的 skill，绝不丢。
如果说 Planning 是一次性 alignment，Skills 就是长期可复用的组织记忆。垂直 AI 公司的护城河，本质上就是「多少业务知识沉淀进了 skills」——这是单纯换基础模型换不掉的资产。
5.4 Elicitation：让 Agent 主动来找你
Skills 再丰富，也会有空白地带。真实复杂任务里，永远会遇到「没人写过 skill」、「几个 skill 之间冲突」、「信息不充分」的情况。
这时候，更合理的姿势是Elicitation——Agent 主动停下来问人。
但 Elicitation 不是「随时弹窗骚扰你」这么粗暴。一个工程上比较成熟的实现包括：
- 能继续就继续，不要无谓阻塞。Agent 遇到不确定时，先按一个合理的默认值继续往下推进。
- 写决策日志（Decision Log）。所有由 Agent 自行做出的、本应该由人决策的选择，都写入一份结构化日志：时间、节点、可选方案、采用方案、理由。
- 批量异步审阅。人在合适的时间点回到决策日志，要么 approve、要么 reverse。反转决策时，Agent 自动重跑相关分支。
- 真正必须停下来的情况，才向人发出 question：例如安全、合规、付费、用户外发、不可逆动作。
这套模式带来的体验是：
- 工作不停。人不需要 7x24 守着 Agent。
- 控制不丢。人随时可以倒回去看决策、改决策。
- 重要的事，仍然由人拍板。
这才是「高带宽 + 高 Control」 的真正含义：人不是去陪 Agent 一句一句聊，而是去检阅一份结构化的决策清单。
六、为什么 Chat 撑不起复杂 Agent
现在可以回到开篇那个三十分钟的失败案例。它的根本问题，其实可以一句话概括：用一维通道驱动一棵高度并行的工作树。
Chat 作为协作界面有几个无法克服的硬伤：
- 线性：消息一条一条往下排，你看见的永远是「最近一句」。一棵工作树根本没法塞进这种结构。
- 低带宽：你只能用一段文字描述意图、用一段文字接收结果，所有结构信息都被压成 token 序列。
- 上下文易腐烂：长对话必然触发 compaction / summarization，中间状态被压缩，细节被丢弃。
- 审阅成本极高：让你在一段 30 屏长的对话里找出哪里改对了、哪里改错了，几乎不可能。
- 无法精准定位：你很难指着对话里的某一段说「只改这里、别动其他」。
更糟的是，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 工程真正值得花十年的方向。
