如何查看AgentSpace模型接入日志信息

在 Agent.Space 中接入大语言模型时，清晰的日志和状态反馈是排查问题的关键。需要明确的是，平台提供了两条独立的查看路径：一是管理工作区内部使用的“自有模型”连接状态，二是追踪外部客户端通过 Developer API 发起的调用记录。这两者使用不同的凭据体系，记录入口也完全不同。本文主要介绍网页界面上可见的检测提示、错误信息和请求列表，这些内容足以应对大多数日常排查需求，但它们并非服务器底层的原始系统日志。

开始查阅前，建议先明确当前的接入方向、目标模型名称、问题发生的大致时间以及所使用的账号。即使模型名称相同，不同的接入方式也可能指向完全不同的服务入口；仅看到一次成功的回答，并不足以证明所有后续请求都经过了预期的服务通道。

工作区设置中的自有模型管理入口

关于自有模型的检测结果

自有模型的连接管理位于工作区的设置页面中。由工作区所有者进入“工作区设置”，找到“自有模型”选项卡，这里列出了已保存的供应商连接配置。

保存连接成功并不代表所有关联模型都已通过兼容性验证。点击具体模型后，可以查看其兼容性检测结果及详细提示。检测过程不仅测试文字回复能力，还会模拟调用工具、接收工具返回结果并继续生成回答的全流程。如果接口协议或功能能力不匹配，界面会显示具体的失败原因、Model ID 以及适用的 Agent 类型。

请注意，不要试图通过修改显示名称来将不兼容的模型伪装成受支持的型号。每次重新检测都可能产生实际的供应商调用费用，因此在已有明确失败信息时，应先仔细阅读结果，调整配置后再进行测试，避免无意义的重复操作。

关于自有模型的检测结果

关于对话中的模型菜单

只有通过兼容性检测的自有模型，才会按供应商分组出现在新建对话时的可用模型列表中。这一列表还受到当前所选 Agent 类型的兼容性约束。

如果在云端环境运行期间新增或修改了模型配置，系统通常会提示需要重启相关服务。完成重启后，再次打开模型菜单进行核对，确认新配置的模型是否已上线。模型出现在菜单中，仅表示该配置在当前环境下可选；要确认实际任务是否真正调用了它，还需结合会话过程中的具体表现，以及供应商后台提供的对应调用记录进行综合判断。

对话界面中的可用模型选择菜单

关于 Developer API 的请求记录

当外部客户端使用 Agent.Space Key 进行开发集成时，相关的调用记录不在工作区设置中，而是位于侧边栏的“更多”菜单下。点击“Model API Key”进入 Developer API 管理页面，找到“Request history”（请求记录）板块。

这里是核对发往 Agent.Space 的 API 请求的核心区域，但它并不是查看所有 Workspace 文件操作的统一日志中心。为了快速定位问题，建议先根据所使用的 Key 进行筛选，再进一步按模型名称或通信协议缩小范围。

将筛选出的记录与客户端发起请求的时间戳、Model ID 和协议类型进行对照，检查请求是否成功到达服务器、是否正常结束，以及记录中显示的计费来源是否符合预期。Key 的名称主要用于识别不同的集成用途，无需将完整的密钥字符串复制到笔记中。如果多个客户端使用了不同的 Key，先锁定正确的那一个，能有效减少将其他任务的调用误判为当前测试问题的情况。

Developer API 的请求历史记录列表

关于失败状态与核对信息

当请求记录显示失败状态时，需要结合多项信息进行综合分析。除了常见的 HTTP Status 和 Error Code 外，还应关注模型标识、通信协议、资金来源字段。如果响应中包含 Request ID，请务必一并保留，这是向技术支持求助时的重要凭证。仅凭一个状态码往往无法直接得出完整的故障原因。

如果客户端报错，但在 Agent.Space 的请求记录中找不到对应项，这通常意味着请求尚未到达平台服务器。此时应重点核对客户端配置的实际请求地址、网络连接状态以及认证信息是否正确。此外，若记录状态仍显示为“待处理”或“需要核对”，则不能将其视为最终的扣费结果。

需要注意的是，自有模型的调用费用由模型供应商直接记录，而 Developer API 的调用则通过 Agent.Space 的路径进行计费。在寻求协助时，请提供准确的时间点、接入方式、模型名称以及脱敏后的错误文字，切勿附带 API Key。只有将产品内部的记录与客户端或供应商的证据对应起来，才能准确判断问题究竟发生在哪一层级。

请求记录详情中的错误信息展示