文章目录引言那个让人崩溃的三十分钟一、垂直 AI 的真问题端到端完成复杂工作1.1 从「增强人」到「替代某段流程」1.2 端到端的难点不在「做」而在「规划与审阅」二、Verifiers Rule可验证性才是真正的分水岭2.1 什么是 Verifiers Rule2.2 同一个领域内任务也是「一字铺开」2.3 别试图「硬刚」不可验证任务三、协作的两个坐标轴信任与控制3.1 Trust我多大程度上不用看你的过程3.2 Control我多大程度上可以把判断喂进去3.3 不同任务落在不同象限四、如何系统性地提升 Trust4.1 把任务往「可验证」的一端拖4.2 任务分解把整块工作拆成可验证的小块4.3 Guardrails通过限制动作空间换取信任五、如何系统性地提升 Control5.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而不是迭代 Prompt8.4 给 Agent 装 Decision Log8.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 去做。一个需要持续控制的任务被塞进一个只允许「扔过去 → 等结果」的聊天框体验崩溃几乎是必然的。四、如何系统性地提升 TrustTrust 不是「多用一阵子就有了」它是可以被工程化提升的。有三种相互配合的手段。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 更聪明但是会让你敢于让它跑久一点。这一点比聪明更重要。五、如何系统性地提升 ControlControl 是这套理论里最容易被低估、也最容易被错误实现的一环。复杂 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 是一次性 alignmentSkills 就是长期可复用的组织记忆。垂直 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 公司对比表、估值表、风险因子表。销售/CRMDocument 客户档案、提案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 工程真正值得花十年的方向。
Agent 不止于 Chat：垂直 AI 时代的协作界面重构
文章目录引言那个让人崩溃的三十分钟一、垂直 AI 的真问题端到端完成复杂工作1.1 从「增强人」到「替代某段流程」1.2 端到端的难点不在「做」而在「规划与审阅」二、Verifiers Rule可验证性才是真正的分水岭2.1 什么是 Verifiers Rule2.2 同一个领域内任务也是「一字铺开」2.3 别试图「硬刚」不可验证任务三、协作的两个坐标轴信任与控制3.1 Trust我多大程度上不用看你的过程3.2 Control我多大程度上可以把判断喂进去3.3 不同任务落在不同象限四、如何系统性地提升 Trust4.1 把任务往「可验证」的一端拖4.2 任务分解把整块工作拆成可验证的小块4.3 Guardrails通过限制动作空间换取信任五、如何系统性地提升 Control5.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而不是迭代 Prompt8.4 给 Agent 装 Decision Log8.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 去做。一个需要持续控制的任务被塞进一个只允许「扔过去 → 等结果」的聊天框体验崩溃几乎是必然的。四、如何系统性地提升 TrustTrust 不是「多用一阵子就有了」它是可以被工程化提升的。有三种相互配合的手段。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 更聪明但是会让你敢于让它跑久一点。这一点比聪明更重要。五、如何系统性地提升 ControlControl 是这套理论里最容易被低估、也最容易被错误实现的一环。复杂 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 是一次性 alignmentSkills 就是长期可复用的组织记忆。垂直 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 公司对比表、估值表、风险因子表。销售/CRMDocument 客户档案、提案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 工程真正值得花十年的方向。
