对象不是流：Copilot ACP 把 SimpleNamespace 塞进迭代器后的连锁崩溃

有些 Agent 报错看起来像 provider 不稳定：

API call failed
Non-retryable error
trying fallback
Aborting

但真正的问题可能很底层：协议适配器拿到的是一个对象，却把它当成可迭代的 streaming 数据来处理。

NousResearch/hermes-agent issue #16271 记录的就是这种典型适配层错误。用户使用 copilot-acp provider，模型是 claude-opus-4.7，endpoint 是：

acp://copilot

结果请求失败：

TypeError: 'types.SimpleNamespace' object is not iterable

这不是模型不会回答，也不是 API Key 错，更不是简单重试能解决的问题。

这是 ACP Copilot CLI 的 streamable HTTP response 没有被正确解析。

错误日志透露了什么？

issue 里的日志很短，但信息密度很高：

⚠️  API call failed (attempt 1/3): TypeError
   🔌 Provider: copilot-acp  Model: claude-opus-4.7
   🌐 Endpoint: acp://copilot
   📝 Error: 'types.SimpleNamespace' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'types.SimpleNamespace' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
   🔌 Provider: copilot-acp  Model: claude-opus-4.7
   🌐 Endpoint: acp://copilot
   💡 This type of error won't be fixed by retrying.

Error: 'types.SimpleNamespace' object is not iterable

几个关键点：

provider 是 copilot-acp；
endpoint 是 acp://copilot；
HTTP status 是 None；
错误类型是 Python TypeError；
系统判断为 non-retryable；
fallback 也救不了。

这说明请求并不是远端返回了一个标准 4xx / 5xx。

它更像是在本地解析/适配 response 的过程中，代码对返回结构做了错误假设。

为什么 SimpleNamespace 不能被当成 iterable？

types.SimpleNamespace 是 Python 里一种很轻量的对象容器。

它适合这样访问：

obj.foo
obj.bar

但它不是 list，不是 generator，也不是 async iterator。

如果某段代码期待：

for chunk in response:
    ...

但实际拿到的是：

SimpleNamespace(...)

就会出现：

'types.SimpleNamespace' object is not iterable

这类错误的重点不是 SimpleNamespace 本身，而是上游返回结构和下游消费方式不匹配。

ACP 场景为什么更容易出现这种错？

ACP，也就是 Agent Communication Protocol，本质上是在 Agent 与外部工具/模型/CLI 之间建立一层协议适配。

它不是传统的：

HTTP JSON request → HTTP JSON response

很多 ACP provider 会涉及：

streamable response；
event message；
JSON-RPC 风格结构；
CLI bridge；
stdout/stderr；
object wrapper；
async stream；
partial result；
final result。

如果适配层没有清楚区分“事件流”和“最终对象”，就容易把对象当 chunk 流处理。

这正是 #16271 的核心。

评论里的线索：它不是孤立问题

维护者评论指出：

Likely duplicate of #14437 — same copilot-acp SimpleNamespace iteration crash.
Fix PRs: #15365 (api_mode detection), #14442 (NotImplementedError guard), #14438 (full streaming), #12274.

这说明问题不是单次用户环境异常，而是 Copilot ACP streaming 支持链路中的一类已知缺陷。

几个修复方向也很有信息量：

api_mode detection：先判断当前 API 返回模式；
NotImplementedError guard：未实现路径不要伪装成可运行；
full streaming：真正支持 streaming，而不是半截兼容；
其他适配修复：补齐 ACP response 的消费逻辑。

换句话说，这不是给 TypeError 外面包个 try/except 就结束。

真正要修的是协议层对返回模式的识别。

“重试三次”为什么没用？

很多 API 错误可以重试，例如：

timeout；
502；
rate limit；
connection reset；
incomplete chunked read。

但这个错误不属于那类。

SimpleNamespace object is not iterable 是本地代码路径错误。

只要输入结构不变，重试 100 次也会得到同样的 TypeError。

所以日志里说：

This type of error won't be fixed by retrying.

这个判断是对的。

问题在于：用户需要知道这不是 provider 临时抽风，而是 Hermes / ACP adapter 的版本或实现能力问题。

正确的修复思路：先识别 response 形态，再决定消费方式

一个健壮的 ACP adapter 至少要区分这些情况。

1. 普通一次性对象

例如：

SimpleNamespace(content="...", status="completed")

这种不能直接 for-loop。

应该读取字段，转换成 Hermes 内部统一 message/result 格式。

2. 同步 iterable stream

例如：

for event in response:
    handle(event)

这种才适合普通迭代。

3. 异步 stream

例如：

async for event in response:
    handle(event)

这种要走 async iterator。

4. 未实现 streaming

如果某个 mode 还没实现，应该明确抛出 NotImplementedError，并给出可读错误，而不是让用户看到 SimpleNamespace TypeError。

5. 混合结构

有些 provider 会先返回 wrapper，再从 wrapper 里取 stream。

这种要明确解包字段，而不是假设顶层 response 就是可迭代对象。

用户怎么快速判断是不是这个问题？

如果你看到下面组合，就基本可以定位到 ACP adapter 层：

Provider: copilot-acp
Endpoint: acp://copilot
Error: 'types.SimpleNamespace' object is not iterable
HTTP None
Non-retryable client error

这时不建议优先折腾：

API Key；
DeepAI base_url；
模型上下文窗口；
网络代理；
provider fallback；
重试次数。

更应该检查：

Hermes 版本是否包含 Copilot ACP streaming 修复；
是否命中了 #14437 / #16271 同类问题；
copilot-acp 是否支持当前模型和当前 api mode；
是否有 full streaming 相关 PR 已合并；
是否可以临时切到非 ACP Copilot provider 或标准 OpenAI-compatible provider。

为什么这类错误对 Agent 特别致命？

普通脚本遇到 TypeError，最多这次请求失败。

Agent 场景里会更麻烦：

fallback 可能切到另一个 provider，导致输出风格/能力变化；
session 状态可能记录一次失败工具调用；
用户以为是模型不可用；
长任务可能被迫中断；
如果错误发生在 streaming 中途，可能没有完整 final answer。

协议适配层越靠近底部，错误越容易被上层包装成模糊的 “API call failed”。

所以文章标题里的“对象不是流”，其实是这类问题的核心：数据形态不能靠猜。

和 DeepAI API 中转站的边界

DeepAI API 中转站提供标准 OpenAI-compatible API 入口：

Base URL: https://api.deepai.wang/v1
API Key: 你的 DeepAI Key
Model: 以 DeepAI 控制台为准

但 copilot-acp 是 GitHub Copilot + ACP adapter 的专用路径，endpoint 是：

acp://copilot

这和标准 OpenAI-compatible HTTP API 不是一回事。

所以如果你遇到 SimpleNamespace object is not iterable，不要把它归因到 DeepAI API 中转站。这类错误发生在 Hermes 的 Copilot ACP 适配层，而不是 DeepAI 的模型转发层。

更实际的建议是：

需要标准模型 API：用 DeepAI / OpenAI-compatible provider；
需要 GitHub Copilot ACP：升级 Hermes，确认 Copilot ACP streaming 修复是否包含在当前版本；
不要把 acp://copilot 当成普通 https://.../v1/chat/completions。

FAQ

`SimpleNamespace object is not iterable` 是模型错误吗？

不是。它是本地 Python 代码把对象当成 iterable 使用时产生的 TypeError。

重试能解决吗？

通常不能。只要 response 结构不变，重试仍会走同一条错误代码路径。

为什么 HTTP status 是 None？

因为错误可能发生在本地适配/解析阶段，而不是远端返回了标准 HTTP 错误码。

该查 API Key 吗？

如果日志已经明确是 SimpleNamespace object is not iterable，优先查 Hermes Copilot ACP adapter 版本和相关修复，而不是 API Key。

DeepAI API 中转站会导致这个错误吗？

不会。这个错误属于 copilot-acp / acp://copilot 路径，和标准 OpenAI-compatible DeepAI API 不是同一层。

总结

#16271 的教训非常工程化：

不要在协议适配层猜 response 是流。

ACP Copilot CLI 返回的 streamable data 可能是对象、wrapper、同步流、异步流或尚未实现的模式。Hermes 只有先识别 response 形态，再选择消费方式，才能避免 SimpleNamespace object is not iterable 这类本地崩溃。

对用户来说，看到这个错误时也别急着怀疑模型或中转 API。真正该查的是 Copilot ACP adapter 的 streaming 支持和版本修复。