为什么代码层面写死了只能以 bot 身份发

[growmuye]

[amdoi7]

我们这边在把 lark-cli 作为上层系统的官方 CLI 执行面集成时，也遇到了同一个问题，补充一下更具体的使用场景。

这不只是“为什么只能以 bot 身份发消息”，而是 CLI 目前缺少更通用的身份切换 / token 注入能力，导致它很难被外部系统稳定地包一层做路由。

我们的实际诉求：

• 支持更通用的身份切换，例如 --as bot / --as user
• 支持直接临时注入 token，例如 --access-token <token>
• 最好支持“每次调用临时注入”，而不是强依赖全局登录态 / 持久 config
• 这样外部系统可以在一层 wrapper 中按请求动态选择 bot / user / token，做多 bot / 多身份路由

这对集成方的重要性在于：

• 上层系统通常已经自己管理凭证，不适合再让 CLI 接管完整 auth 生命周期
• 某些场景需要显式 user token，而不是 bot token
• 如果只能走固定身份或全局状态，集成方往往只能回退到自己实现 API client

如果后续支持，比较理想的形式可能是：

• --as user
• --access-token <token>
• 明确优先级：显式 token > profile/login state
• 在 api 和各 service / shortcut 命令上都可用

这样 CLI 不仅适合终端里的人直接使用，也更适合被 AI agent、orchestration system、wrapper CLI 集成。

[meikidd]

+1，目前很难集成进入 ci/cd 流程里去，需要支持显式 token

[haozhenghua-code]

Thanks for the suggestion, and for sharing the detailed integration scenarios here.

This is a very valuable direction for us. We agree that identity flexibility is important when lark-cli is used as an execution layer
for AI agents, wrapper CLIs, and CI/CD systems.

We will evaluate two related improvements:

1. support for sending messages as --as user
2. support for passing UAT/TAT directly per invocation

Thanks again for the detailed feedback and concrete use cases. They are very helpful for shaping the design.