程序化访问

程序化访问适用于没有浏览器，或不应依赖人工登录的软件。你可以在 With 门户中管理两类内容：

执行主体：由你的账户直接行动，或创建独立的智能体、自动化。
登录凭证：使用访问密钥，或注册由你保管私钥的公钥。

创建主体或凭证不会自动获得应用内权限。目标应用仍会决定它接受哪些登录方式，以及登录后可以执行什么操作。

先判断是否需要程序化凭证

flowchart TD
    Start[软件需要登录应用] --> Browser{运行时能否由用户<br/>在浏览器中确认登录？}
    Browser -->|能| Device[优先考虑设备码授权]
    Browser -->|不能| Actor{是否需要独立标识<br/>和单独停用？}
    Actor -->|不需要| Account[使用账户作为主体]
    Actor -->|需要| Behavior{工作方式更接近哪一种？}
    Behavior -->|根据上下文决定下一步| Agent[创建智能体]
    Behavior -->|按计划或事件执行固定流程| Automation[创建自动化]
    Account --> Credential{选择凭证}
    Agent --> Credential
    Automation --> Credential
    Credential -->|希望配置简单| AccessKey[访问密钥]
    Credential -->|希望私钥始终留在本地| PublicKey[公钥登录]

设备码授权通常更适合由人启动的 CLI 或桌面工具。它不要求你长期保存一份程序化凭证。无人值守的服务、智能体和自动化，则更适合使用访问密钥或公钥。

智能体还是自动化

选择	适合的场景
智能体	会读取上下文、选择工具或动态决定下一步的程序。
自动化	按计划、Webhook 或其他明确事件执行固定流程的任务。

两者都归你的账户所有，也使用相同类型的凭证。分开管理的价值在于名称、用途和生命周期更清楚：暂停一个部署自动化，不会影响你的个人账户或其他智能体。

访问密钥还是公钥

选择	特点
访问密钥	创建快、接入简单；密钥值只显示一次，需要安全保存。
公钥	私钥始终由你保管；适合已经有密钥管理或签名能力的环境。

选择访问密钥还是公钥，取决于凭证保管方式、目标应用支持的方式，以及现有工具能否完成签名。

日常检查

名称写清楚用途和运行位置，例如“发布助手”或“夜间备份”。
每个服务使用独立凭证，不要在多个环境之间共用。
不再使用时及时撤销；只是临时停机，可以先暂停对应主体。
定期查看会话安全，确认登录应用和执行主体符合预期。