# 同事打开我分享的 Agent，只看到权限错误。 | EasyNet

Source: https://easynet.run/cases/problems/explain-missing-agent-access

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 同事打开我分享的 Agent，只看到权限错误。

你把调好的助手发给同事，他能打开聊天，一查报价就报错。你不知道他少了知识库权限、运行设备没连上，还是报价服务已经停止。分享本来应该减少重复配置，最后却变成你远程看他的屏幕，逐个猜哪里出了问题。

单一平台已有清楚的权限提示，就使用它。多个设备和业务服务共同参与时，才需要把依赖说明放到一起。让接收者先知道完成任务需要哪些条件，比把所有错误翻译成“请联系管理员”更有用。

可以从一项报价任务列出实际依赖：助手入口、报价查询函数、维护它的运行服务，以及接收者对业务资料的授权。EasyNet 的资源和调用状态能参与检查；哪些依赖属于这项 Agent、如何向用户解释，还需要由维护者声明并接到产品界面。

检查必须使用同事自己的身份。若借你的账号先跑成功，只能证明你能用，不能证明分享完成。身份未配置、服务离线和业务访问被拒绝也应分别处理：前者需要登录或连接，第二种找维护者，第三种按资源负责人的流程申请。

提示不能为了详细而泄露无权查看的内容。可以告诉同事缺少完成报价所需的授权，并提供获准展示的申请入口，不必列出所有私人知识库名称。申请也只是请求，得到批准以后仍要重新检查；外部系统的授权可能需要在它自己的管理界面完成。

拿一个没有预先配置过的同事账号试一次，从错误提示走到正确处理人，再完成最小报价任务。如果仍需要你口头解释每个环节，依赖说明就还不够。可用的分享应让对方知道下一步怎么做，而不是只拿到一个只能在作者电脑上工作的链接。

01

以接收者检查

不要借作者身份验证分享。

02

区分失败原因

登录、离线、业务拒绝各自处理。

03

修复后实际报价

批准后重新核验原任务。

让错误指向正确下一步，而不是借作者账号重试。

为三种故障给出不同下一步

本地显示逻辑示例，状态必须来自真实检查；不要通过文案猜测权限。
本地示例 · python

```
next_step = {
    'unauthenticated': 'Sign in with your own account',
    'offline': 'Contact the service maintainer',
    'denied': 'Request task access from the resource owner',
}
for state, action in next_step.items():
    print(f'{state}: {action}')
```

预期结果：三种状态分别引导登录、联系维护者与申请授权，不暴露私有资源内容。

接入时的检查项

能够区分离线、未登录和访问被拒绝。

申请流程不会泄露未授权资源的内容。

批准后使用接收者身份完成实际操作。

源码与接入资料

[设备接入指南](https://easynet.run/docs/connect/runtime)

[MCP 接入指南](https://easynet.run/docs/connect/mcp)