AI Agent 的下一步:不是更会聊天,而是更会交付真实工作

这两年很多人第一次认真感受到 AI agent 的能力，是从写代码开始的。
原因很简单：代码这件事天然适合 agent。它有文件，有命令，有测试，有报错，有 diff，也有版本管理。一个 agent 改完代码之后，我们至少可以问几个很具体的问题：测试过了吗？哪里变了？能不能复现？有没有截图？CI 过了吗？
所以 coding 很自然地成了第一块试验田。
但如果只把 agent 理解成“更会写代码的 AI”，可能会低估接下来真正重要的变化。更大的变化是：agent 正在从 coding 走向更广泛的 knowledge work，再进一步走向 personal agent 和 enterprise agent。
也就是说，它不只是帮你写一个函数，而是开始进入真实工作流程：查资料、读文档、整理上下文、做安全审查、复现 bug、写报告、处理内部系统里的任务，甚至长期理解一个人的工作习惯。
这听起来很诱人，但真正困难的地方也在这里。
因为真实工作不像一次聊天。真实工作有上下文，有权限，有环境，有风险，有验收标准。一个 agent 说“我完成了”，其实不够。我们真正需要的是：它能不能把事情做完，并留下别人可以检查的证据。

从写代码到做工作，难点变了
写代码时，agent 的边界相对清楚。
它读代码，改文件，跑测试，提交 diff。即使它犯错，人类也有很多办法发现：测试失败、编译失败、代码 review 不通过，或者运行效果不对。
但 knowledge work 不一样。
比如让 agent 帮你整理一份行业报告。它可能读了很多网页，看起来总结得很流畅，但你怎么知道它没有漏掉关键来源？怎么知道它没有把旧消息当成新消息？怎么知道它没有把一个人的推文理解成官方发布？
再比如让 agent 帮团队处理内部流程。它可能要查文档、读表格、调用 API、通知同事、改配置。这里的问题就不是“回答得好不好”，而是：它有没有权限做这件事？它拿到的上下文是不是对的？它改了什么？失败了能不能恢复？
所以 agent 进入真实工作后，核心挑战会从“模型聪不聪明”，变成“流程能不能被控制”。
真正有用的 agent，要能把复杂工作拆开
一个很值得注意的方向，是用很多 agent 并行处理复杂任务。
安全审查就是典型例子。过去一个安全团队要审一个大代码库，可能要花很长时间：读依赖、看鉴权、找输入输出、复现漏洞、写报告。现在更合理的方式可能不是让一个超级 agent 从头看到尾，而是把任务拆成很多小块：
一个 agent 专门查依赖风险；
一个 agent 专门看鉴权绕过；
一个 agent 专门找敏感信息泄漏；
一个 agent 专门复现可疑路径；
一个 agent 专门整理证据和修复建议。
这样做的重点，不是制造一堆“看起来很忙”的 agent，而是让每个 agent 都有清楚的任务边界、运行环境和输出格式。
它们最好在 sandbox 里运行，避免误操作真实系统；它们要留下证据，说明自己看了哪些文件、跑了哪些命令、发现了什么风险；最后再由一个汇总流程把这些证据合成报告。
这其实是 agent 工作流的一个重要原则：复杂任务不要只靠一个长上下文硬撑，而要拆成可验证的小任务。

但拆开还不够，还要能复现
真实工作里最让人不放心的，不是 agent 不会说，而是它说得太像真的。
尤其是修 bug、做 QA、做安全审查这种任务，光有文字解释是不够的。一个靠谱的 agent 应该能进入一个临时环境，把问题发生时的状态搭出来，复现 bug，完成修复，再用截图、视频、测试结果或者日志证明修复有效。
这也是为什么远程浏览器、远程桌面、VNC、临时 CI 环境这类东西会变重要。
未来我们判断一个 agent 有没有把活干完，可能不会只看它最后写的一段总结，而会看它有没有留下这些东西：
复现环境是什么；
执行了哪些步骤；
bug 原来怎么出现；
修复后怎么验证；
截图或视频在哪里；
测试结果是什么；
如果失败，恢复路径是什么。
这听起来像工程细节，但它其实决定了 agent 能不能进入更严肃的工作。
因为真实团队不需要一个只会说“我觉得修好了”的助手。真实团队需要一个能把证据贴到 PR 里、让别人快速复核的工作伙伴。

这和医疗 agent 评测是同一个思想
这个思路不只适用于软件。
今天看到的 PhysicianBench 也在讲类似的事情，只是它把场景换成了医疗 EHR 工作流。
医疗 agent 的评测不能只问：“这个医学问题回答得对不对？”因为真实医生工作不是答题比赛。它可能要查病人记录、看历史 encounter、调取检查结果、判断下一步动作、生成文档，还要保证每一步都符合流程。
所以 PhysicianBench 的关键不是又做了一个问答榜单，而是把任务放进更接近真实系统的环境里，用一系列 structured checkpoints 去检查 agent 的每一步。
这和软件 QA 里的“复现 bug、修复、贴视频到 PR”其实是一个底层概念：execution-grounded evaluation。
用大白话说，就是：
不要只问 agent 会不会讲，而要让它真的做一遍，然后检查过程和结果。
软件场景里，证据可能是截图、视频、测试和 PR。
医疗场景里，证据可能是 EHR API 调用、任务 checkpoint、医生审查。
安全审查场景里，证据可能是代码位置、漏洞路径、复现命令、影响范围。
场景不同，但核心一样：agent 必须在环境里行动，并留下可验证证据。

Personal agent 也绕不开这个问题
很多人期待 personal agent：它懂你的文件，懂你的目标，懂你的偏好，能长期帮你处理事情。
这个方向当然很有想象力。但越 personal，越不能只靠“模型懂我”。
因为 personal agent 会碰到很多边界问题：
哪些文件它可以读？
哪些文件它不能碰？
它能不能替你发消息？
它能不能改日历？
它能不能删除或移动资料？
它做错了能不能恢复？
它怎么知道这次任务和你长期偏好一致？
所以 personal agent 的真正难点，可能不是“它有没有记忆”，而是“它有没有一套可控的工作系统”。
它需要记忆，但不能乱记。
它需要工具，但不能乱用。
它需要主动性，但不能越界。
它需要总结能力，但更需要证据链。

对普通人来说，应该练什么
如果你不是做模型训练的人，也不是 agent 平台工程师，那这件事对你有什么用？
我觉得最实用的练习不是追每一个新工具，而是开始用 agent workflow 的方式重新设计自己的工作。
你可以拿一个真实任务来练，比如每日信息整理、PR review、日志诊断、文件归档、竞品分析，然后问四个问题：
第一，它需要哪些上下文？
也就是 agent 要读什么资料，哪些是官方来源，哪些只是参考，哪些历史内容不能重复。
第二，它可以使用哪些工具？
比如搜索网页、读本地文件、跑脚本、截图、访问 API、生成报告。
第三，哪些动作必须经过你确认？
读文件可能可以自动，写文件可能要分情况，删除、发送、发布、覆盖已有内容一定要更谨慎。
第四，它怎么证明自己做完了？
是测试结果、截图、event log、source list、diff，还是 checklist？
这四个问题比“哪个模型最强”更贴近日常工作。因为模型会变，但真实工作里的上下文、权限、验证和恢复，一直都需要设计。
结论
AI agent 的下一步，不是更会聊天。
它的下一步，是更会进入真实工作：理解上下文，拆解任务，调用工具，复现问题，完成修复，留下证据，并在出错时能恢复。
coding 是第一块试验田，因为代码天然可验证。
knowledge work 是下一块更大的场地，因为很多人的工作本质上就是处理信息、判断上下文、推进流程。
personal agents 和 enterprise agents 则会把问题继续放大：当 agent 越来越懂你、越来越能行动，我们就越需要清楚的边界和证据闭环。
未来有用的 agent，可能不是那个最会说“我明白了”的 agent。
而是那个能告诉你：
我读了什么。
我做了什么。
我怎么验证的。
哪里失败了。
下一步怎么恢复。
这才是从聊天助手走向真实工作伙伴的关键一步。

参考来源
Peter Yang, X post, 2026-05-05: https://x.com/petergyang/status/2051508988936937764
Guillermo Rauch, X post about deepsec, 2026-05-04: https://x.com/rauchg/status/2051386798899888539
Peter Steinberger, X post about Crabbox/WebVNC QA workflow, 2026-05-05: https://x.com/steipete/status/2051557150040711425
Peter Steinberger, X post about Crabbox 0.5.0, 2026-05-05: https://x.com/steipete/status/2051485798613111116
PhysicianBench, Hugging Face Papers: https://huggingface.co/papers/2605.02240