AI 产品
发布时间 2026.05.19
Agent over Agent
AI 缩短了执行时间，但没有降低项目本身的复杂度。未来的远程支持不会只是在用户电脑上远程操作，而会变成支持方 Agent 与用户侧 Agent 之间的诊断、授权和协作。
Thesis
未来远程支持的核心形态，很可能不是电脑控制电脑，而是Agent over Agent：支持方不再只接管屏幕，而是通过用户侧 Agent 进入真实上下文，完成诊断、边界确认、修复尝试和人工升级。
最近做机器人部署和 AI 工具调用指导时，我越来越明显地感觉到一件事：项目复杂度其实没有下降，甚至还在提升。
AI 把很多执行时间压短了。以前一天才能排查完的问题，现在可能十分钟就能跑一轮。但这不代表问题变简单了，只是更多复杂性被压缩到了更短的时间里。
这会带来一个很现实的变化：初步沟通时的问题定位变得更难了。用户说“它不 work”，背后可能不是一个按钮、一个权限、一个脚本的问题，而是一串 Agent、工具、环境、设备和真实场景之间的错位。
Argument
传统远程支持的前提很简单：人看到同一块屏幕，就能大致进入同一个问题现场。
所以过去的远程控制主要是电脑控制电脑。用户共享屏幕，支持方接管鼠标键盘，看日志、点设置、重装驱动、调整配置。这个模型成立，是因为问题大多发生在可见界面、固定软件和相对稳定的操作路径里。
但 AI 工具和机器人部署里的问题现场，已经不只在屏幕上了。它可能在 prompt 里，在 skill 边界里，在工具权限里，在本地环境里，在云端 API 状态里，也可能在机器人和物理世界的交互里。
更麻烦的是，用户自己也不一定知道问题发生在哪一层。用户看到的是结果不对，但系统内部可能经历了意图理解、任务拆解、工具选择、参数填充、执行反馈、异常处理好几层变化。
这就是为什么初步沟通会变难。AI 让每一步都更快，但也让一次失败包含更多可能性。过去我们是在问“你点到哪一步出错了”，现在更像是在问“你的 Agent 是怎样理解这个任务，又在哪个边界上偏掉了”。
一个自然的中间形态，是给用户一个 skill，让用户自己的 AI 先跑。这个 skill 可以列出边界场景：权限是否完整，工具是否可达，配置是否缺失，环境是否一致，输入是否超出能力范围，外部设备是否在线。
这一步是有价值的。因为很多问题不需要支持方一上来接管，只需要用户侧 Agent 按标准流程跑一轮，就能把模糊描述变成结构化报告。它会比人工来回问快，也更贴近本地上下文。
但它可能还不充分。因为支持不是单纯收集信息。真正棘手的地方常常在判断：哪些异常可以忽略，哪些需要回滚；哪些权限可以临时开放，哪些不能碰；哪些修复应该让 Agent 自动尝试，哪些必须等人确认。
所以远程支持的对象会继续变化。它不再只是屏幕，也不只是用户。它会变成用户侧 Agent 所托管的上下文、权限和执行面。
未来的支持方可能会派出自己的 Agent，不是直接夺取用户电脑，而是和用户侧 Agent 对话：要求它运行诊断、读取必要日志、复现失败路径、尝试低风险修复，再把高风险动作交回给人确认。
这就是 Agent over Agent。不是一个 Agent 暴力控制另一个 Agent，而是一个支持层 Agent 覆盖在用户工作现场之上，管理诊断链路、权限边界和升级路径。
这里真正被控制的，也许不是电脑，而是问题定位过程。谁有权看哪些上下文，谁能执行哪些命令，哪些动作需要用户确认，哪些结论需要支持方复核，这些会比鼠标键盘本身更重要。
Implications
- ·远程支持产品会从 screen sharing 转向 context sharing。屏幕仍然有用，但它会变成证据之一，而不是唯一现场。
- ·支持方需要提供的不只是文档或客服，而是一套可被用户侧 Agent 执行的诊断协议：边界场景、检查顺序、失败归因和修复权限。
- ·权限设计会变得更重要。Agent over Agent 如果没有清楚的授权、审计和回滚机制，很容易从支持能力变成风险入口。
- ·机器人和 AI 工具部署会更早需要这种形态，因为它们的问题现场天然跨软件、硬件、环境和真实世界。
Closing
所以我现在更愿意把未来远程支持看成一种代理关系，而不是一种远程控制关系。电脑控制电脑解决的是操作距离，Agent over Agent 解决的是复杂系统里的问题定位、权限边界和可托付修复。