当 Agent 说"我做不到"时
那天随手问了一句："火山方舟现在我还有多少余额？"
Agent 的回答很干脆：无法直接访问账户余额，没有账户凭据或 API 访问权限。
我愣了一下。AI 助手，连查个余额都不行？内心第一反应是怀疑——这工具到底有什么用？
但我没有急着吐槽，而是追了一句："为什么不能查？不是 AI 吗？"Agent 还是解释权限问题。到这里，大多数人会停下来，要么抱怨工具不行，要么直接放弃这个查询路径。
我没有。因为我注意到一个更重要的问题：我对这个工具的期望，和它的实际边界不匹配。而这个不匹配，比"做不到"本身更有价值。
期望与边界的错位
我期望的是一个能替我操作一切的超级助手。但火山方舟的平台设计里，账户数据是受保护的用户隐私——即使 Agent 有通用能力，它也拿不到我的登录状态和 API 凭证。
这不是 Agent 能力不足，而是系统有边界。就像 ATM 能查余额但不能跨行转账，每个系统都在自己的功能范围内运行。银行系统的边界是物理的——ATM 只能访问本行数据。火山方舟的边界是逻辑的——账户数据需要用户自己的凭据才能访问。
两种边界的表现形式不同，但本质相同：超出边界的能力不存在。你不能让 ATM 替你跨行转账，也不能让没有凭据的 Agent 替你访问你的账户数据。这不是"暂时做不到"，而是"永久做不到"——除非你给它凭据，就像给 ATM 一个跨行转账的授权一样。
很多人遇到"做不到"的回答时，会直接跳到"换一个工具"。但换工具不一定解决问题——下一个工具可能也有类似边界。真正要问的是：这个"做不到"到底是能力问题还是权限问题？
如果是能力问题，那确实该换工具。比如你要做数据可视化但 Agent 只能写文字，那是能力不足。如果是权限问题，那应该调整你的协作方式，而不是换工具。比如你要查余额但 Agent 没有你的账户凭据，那是权限受限。
两种问题的解决路径完全不同，混在一起只会浪费时间。能力问题用更好的工具解决，权限问题用不同的协作方式解决。
换一个问题，换一条路
我调整了策略，不再问"我的余额是多少"，而是问"火山方舟平台上有哪些方式可以查看自己的账户信息"。
这一转变很关键。前一个问题要求 Agent 替我操作——你帮我查。后一个问题让 Agent 告诉我操作路径——你告诉我怎么查。从执行者变成导航者，Agent 的角色变了，它能给出的信息也变了。
结果 Agent 给出了几个可行方案：登录官网、APP 查询、API 文档里的接口说明。每个方案都不需要 Agent 有账户凭据——因为方案本身不涉及凭据操作，只涉及路径指引。
最后我通过官网查到了余额。整个过程花的时间比直接问多了一些，但收获比直接查余额大得多——我不仅知道了余额，还知道了火山方舟的信息访问边界在哪里。下次再需要查询任何账户信息，我不会再走"直接问 Agent"这条弯路，而是直接走"导航 → 自己操作"的路径。
从"为什么不能"到"怎么才能"
这次经历让我提炼出一个小卡点里的协作方法：
当你遇到 Agent 说"做不到"时，不要急着跳到"怎么做"，先问"为什么不能"。如果原因是权限或边界，那下一步不是突破边界，而是找到边界内的最优路径。
具体来说，分三步走：
- 先判断"做不到"的原因——是能力不足还是权限受限？能力不足的特征是"我能做但做不好"，权限受限的特征是"我根本没资格做"。
- 如果是权限受限，问 Agent："在你的能力范围内，你能告诉我什么？"这句话把 Agent 从执行者切换为导航者。执行者需要凭据才能操作，导航者只需要知识就能指引。
- 把导航信息转化为自己的操作路径。Agent 不能替你登录官网，但它能告诉你官网在哪、怎么查。你自己去查，比等 Agent 突破权限边界更现实。
这个方法看起来简单，但我在后续很多场景里反复用到。每次 Agent 说"我无法访问"或"我没有权限"，我的第一反应不再是失望，而是自动切换到导航模式。
这个方法还有一个应用场景：当你需要做多个平台的类似查询时。比如查火山方舟余额、查 AWS 余额、查阿里云余额——每个平台都有自己的边界，每个边界的绕行方式可能不同。但核心方法是一样的：先问"为什么不能"，再问"你能告诉我怎么才能"。方法复用比工具替换更高效，因为方法适用于所有类似场景，而每个工具只适用于一个场景。
因为"做不到"不是终点。它是一条信息：这个任务不在 Agent 的执行范围内，但 Agent 可能知道正确的路径在哪。关键是你要换一种方式去问——从"帮我做"切换到"告诉我怎么做"。这一切换，往往比换一个工具更有效。