Agent.Space Developer API 可以让服务端 Agent 集成使用你在 Agent.Space 账户中可用的模型。可靠的接入顺序是:注册账户并创建独立 API Key、发现该 Key 当前可用的模型、选择客户端需要的协议、发送一个小请求,再到 Request history 核对结果与资金来源。如果目标是把多个 Provider Key 收敛到一个 Endpoint,应在切换生产流量前先参考一个 API Key 访问多个 AI 模型的迁移指南。
不要从旧文章里复制 Model ID,也不要把真实 Key 放进浏览器代码。实时 /v1/models 响应才是模型 ID 与支持协议的事实来源;Developer API 页面则是当前产品入口。
信息核验日期:2026 年 9 月 10 日。 本文已按 Agent.Space 当前产品界面核对 Endpoint、SDK 接入形式、实时模型发现、Request history 字段与资金说明。可用模型、协议、资金规则和产品控制仍可能变化,依赖某项配置前请重新检查实时 Developer API 面板。
**技术审核:**Agent.Space Technical Review 核对了当前产品合同与示例。这是配置审核,不是生产 Benchmark,也不承诺每个模型都暴露完全相同的功能。
Developer API 能做什么
它是面向服务端集成的模型访问层,目前的接入形式包括:
- OpenAI Responses:使用 OpenAI 兼容的服务端 SDK 配置。
- Anthropic Messages:使用 Anthropic 兼容的服务端 SDK 配置。
这些是连接形式,不代表所有 Provider 功能都完全相同。即使模型出现在发现结果中,也仍需支持客户端真正需要的协议和能力。
所选模型还会决定适用哪条 Agent.Space 资金路径。不要假设一种余额不可用时,系统会自动切到另一种余额。开始持续工作负载前,应检查实时产品面板与价格页。
接入前准备四项内容
- 拥有对应套餐额度或 Flex 余额的 Agent.Space 账户。
- 为当前集成或环境单独创建的 API Key。
- 生产 Endpoint:
https://api.agent.space。 - 实时模型发现接口返回的 Model ID。
如果独立轮换能够降低中断风险,本地开发、生产与自动化应分别使用 Key。Key 的名称只用于识别;真正授权消费的是 Secret Value。
第一步:创建并保护 API Key
打开 Developer API 面板,创建一个能说明用途的 Key,例如 Production backend,再把完整值保存到目标 Secret Store。
遵守基本凭据规则:
- Key 只放在服务端环境变量或获批的 Secret Manager 中;
- 不要把它提交到仓库,也不要粘贴到截图、Issue、浏览器 Bundle 或 Prompt;
- 不同环境需要单独撤销时,就分别创建 Key;
- 一旦怀疑泄露,立即轮换或撤销。
本地 Shell 可以使用这样的占位值:
第二步:发现当前可用模型
先查询当前 Key 能访问哪些模型:
使用响应中准确的 id。同时确认 protocols 列表包含客户端将要调用的协议:OpenAI Responses 形式需要 openai.responses,Anthropic Messages 形式需要 anthropic.messages。
主动更换模型时,或者原本有效的 ID 消失时,重新执行发现。Blog 中写死的模型清单会过期,实时返回不会。
第三步:按客户端原生协议接入
应该使用客户端期待的 Base URL,而不是把两种 SDK 配置当成可以互换。
OpenAI Responses 示例
Anthropic Messages 示例
这些示例只记录配置形式,不是性能测试、客户结果,也不证明不同模型的功能完全等价。
第四步:正式流量前先验证一个小请求
第一次请求完成后,在 Request history 中确认:
- 实际使用的是预期 Key;
- Model ID 与协议和配置一致;
- 请求已经到达 Agent.Space,并按预期结束;
- 记录中的资金来源符合你的选择。
评估成本时,应计算一个已验收任务中的所有 Call,而不是只看这次小请求。Coding Agent API 成本计算指南解释了怎样分别处理未缓存输入、Cache、输出、工具与重试,同时避免捏造通用任务价格。
本文没有拿读者的 Key 发送生产请求。示例按 Agent.Space 当前展示的接入形式编写;你自己的小型请求与 Request history,才是所选 Key、模型、协议和资金路径对该账号真实可用的证据。
按固定顺序轮换、撤销和排错
轮换会让旧 Secret 失效,因此应把依赖服务更新纳入同一次切换。集成下线或 Key 可能泄露时可以撤销。重命名只改善管理,不会改变 Secret。
请求失败时,一次检查一层:
- 当前服务端进程是否拿到了完整且有效的 Key?
/v1/models是否仍返回配置中的 Model ID?- 该模型是否列出了客户端使用的协议?
- 当前 SDK 形式对应的 Base URL 是否正确?
- 所选模型需要的资金路径是否可用?
- Request history 是否显示请求到达 Agent.Space?
这个顺序能把认证、模型可用性、协议兼容性、路由和资金问题拆开。一次修改全部变量,只会让故障更难定位。
排错时要把 HTTP 响应与 Request history 放在一起看,不能只凭一个现象猜原因:
HTTP Status 只是线索,不是完整诊断。如果响应带有错误正文或 Request ID,应一并保留;但绝不能把 API Key 本身写进日志、截图或支持消息。
从一个可验证的小集成开始
安全的第一个集成应该很窄:一个用途明确的 Key、一个从实时发现结果选出的模型、一种客户端原生协议,以及一个小型验证请求。只有 Request history 与预期配置一致后,再逐步扩大使用。
先查看 Agent.Space 当前套餐与模型价格,再注册 Agent.Space 账户。账户具备所需资金路径后,回到 Developer API 页面创建集成 Key。
