[Plugin] astrbot_plugin_httpadapter

[Li-shi-ling]

插件信息

{
  "name": "astrbot_plugin_httpadapter",
  "display_name": "HTTP平台适配器",
  "desc": "为 AstrBot 提供 HTTP/HTTPS 接口，支持外部应用通过 HTTP 协议与 AstrBot 交互",
  "author": "lishining",
  "repo": "https://github.com/Li-shi-ling/astrbot_plugin_httpplatform",
  "tags": [
    "平台适配器"
  ]
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_httpadapter

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

框架适配/结构规范

• @filter.command_group("http") 修饰的方法 async def http(self): pass 缺少 event 参数。按要求：除 on_astrbot_loaded 外，所有使用 @filter 的监听器/命令方法签名必须包含 event 参数，否则可能导致框架无法正确注入事件对象或在运行时报错。
• self.httpadapter 在 inithttpadapter 中动态创建，未在 __init__ 初始化；若其它路径先访问该属性会触发 AttributeError（可维护性/健壮性问题）。

逻辑/健壮性

• 版本号解析：version.split('.') 后强制 int(x)，若版本号包含非纯数字（如 4.16.0-beta）会抛 ValueError，当前未捕获该异常（会导致插件初始化失败）。
• other_message 中使用内部属性 event._has_send_oper（以下划线开头），属于框架内部实现细节：升级/变更时容易破坏兼容性，可维护性风险较高。

---

src/init.py

• 空文件，无问题可报告。

---

src/constants.py

代码质量

• 常量以 dict 表示枚举值，缺少不可变约束；运行时可被意外修改导致全局行为漂移（可维护性/安全性风险）。（更稳妥通常用 Enum 或 MappingProxyType 冻结）

---

src/dataclasses.py

代码质量

• 未使用的导入：json（未使用）。会降低可读性并增加误导。

异步类型/健壮性

• PendingResponse.future 类型标注为 asyncio.Future（未参数化），在类型检查与阅读上信息不足；另外如果 future 不是在当前运行 loop 创建，可能出现跨 loop 问题（建议由创建处用 get_running_loop().create_future() 保证归属）。

---

src/http_adapter.py

框架适配（严重）

• 日志导入违规：使用了 from astrbot import logger。按要求 logger 必须且只能 from astrbot.api import logger 导入。否则不符合框架规范，且可能导致日志配置不一致。

功能/逻辑正确性（严重）

• isinstance(message, List) 使用了 typing.List（from typing import ... List ...）。在 Python 3.10 中对 typing.List 做 isinstance 会抛 TypeError（典型错误：Subscripted generics cannot be used with class and instance checks 或类似）。应使用内置 list：isinstance(message, list)。
  • 同类问题在 _handle_http_stream_message 中同样存在。
• _handle_http_stream_message 中：
  • messages = [] 初始化后，若 message 为字符串，messages 仍为 []，随后 if messages is None: 分支永远不会走（messages 不可能是 None），导致 abm.message 被设为 空消息链，而不是预期的 [Plain(text=message)]。
• 标准消息接口返回“双重 JSON 编码”风险：
  • StandardHTTPMessageEvent.send_response() 中 pending.future.set_result(json.dumps(self._cached_response))，future 结果是 JSON 字符串；
  • _handle_http_message() 又把该字符串作为 "response": response 交给 jsonify，客户端拿到的 response 可能是字符串形式的 JSON，而不是结构化数组对象（易造成协议不一致/客户端解析困难）。

安全/最佳实践

• 默认 cors_origins="*" 且 auth_token 允许为空（即不鉴权），会让外部接口在默认配置下暴露到公网时风险极高（任何来源可调用、会话/消息接口可被滥用）。
• _check_auth 仅做固定 token 字符串比较：虽可用，但缺少诸如速率限制、失败计数等防爆破措施（尤其在开放网络下）。

异步/并发与资源管理

• asyncio.Future() 直接构造：在复杂运行环境（多 loop/不同线程）下可能出现 loop 归属问题；更稳妥是 loop = asyncio.get_running_loop(); future = loop.create_future()。
• _cleanup_expired_sessions() 使用 asyncio.create_task(session.close(...)) 但不纳入统一任务管理（你有 _start_task 但这里未用），可能造成：
  • 任务异常无人收集（产生 “Task exception was never retrieved”）；
  • 终止时无法统一取消（资源泄漏/关闭不彻底）。
• terminate() 里对 pending_responses 的处理有重复/冗余逻辑：
  • 前面循环 pop 并 set_exception 后，后面又遍历 self.pending_responses.items() 再 set_exception，一般情况下第二段不会执行到任何对象（降低可维护性）。
• terminate() 清理会话时仅 self.sessions.clear()，没有逐个 await session.close()，会话层如有资源（长连接/订阅/后台任务）将无法确保被正确释放。

协议/实现细节

• SSE 输出中混用非 JSON 数据：
  • yield f"event: ...\ndata: {{'reason': ...}}\n\n" 使用单引号构造“类 JSON”，这不是合法 JSON；多数 SSE 客户端会按字符串处理或解析失败，造成协议不一致。
• server_task 变量定义但从未赋值使用（死代码），并在 finally 中做取消处理，属于可维护性噪音。

---

src/httpmessageevent.py

框架适配（严重）

• 日志导入违规：from astrbot import logger，应改为 from astrbot.api import logger。

代码质量

• 未使用的导入：HTTP_EVENT_TYPE、find_tool_loop_agent_runner_with_stack_info、MessageEventResult、asyncio（文件内未使用）、可能还有 json（仅在 send_response 用到，OK）。
• StandardHTTPMessageEvent 中的 _pending_response 从未被赋值使用（只有读取分支），属于无效状态变量，增加阅读负担。

功能/逻辑正确性

• BMC2Text() 返回的是 json.dumps(component.toDict())，因此 response_text 是 JSON 字符串；你用 if "AstrBot 请求失败。" in response_text 来判断失败，极易误判/漏判（因为文本在 JSON 字符串中的呈现不稳定，且不同组件字段结构不同）。
• StreamHTTPMessageEvent.send() / queue_put_generator() 往队列放入：

  {"type": "...", "data": {...}, "text_type": text_type}

  但 SSE 生成端读取时只取 item.get('data', {}) 并 json.dumps(event_data)，导致 text_type 被丢弃（协议字段实际不会发到客户端），属于明显的数据丢失/协议实现不一致。
• 队列 queue = asyncio.Queue(maxsize=100)：生产端多处 await self.queue.put(...)，当客户端慢/断流导致消费不及时，会在 put 处阻塞，进而阻塞上游 LLM 事件处理链路（潜在“反压”扩散，严重时拖垮整体吞吐）。缺少超时/丢弃策略/断连检测。

---

src/httpsession.py

框架适配（严重）

• 日志导入违规：from astrbot import logger，应为 from astrbot.api import logger。

代码质量

• 大量未使用导入：Any, Dict, List, HTTP_MESSAGE_TYPE, HTTP_EVENT_TYPE, HTTP_STATUS_CODE, HTTPRequestData, PendingResponse, AdapterStats, Plain, asyncio, uuid, AstrBotMessage, MessageMember, MessageType, Platform, PlatformMetadata, register_platform_adapter, json 等，造成可读性显著下降，也暗示该模块可能经历过拷贝粘贴未清理。

功能/资源释放

• close() 仅记录日志，没有更新会话状态、也没有释放/通知适配器侧资源（如果未来会话持有资源，这里会成为泄漏点）；is_active() 依赖 last_active，但本类没有任何更新 last_active 的方法或调用点，活跃度统计可能长期不准确。

---

src/tool.py

框架适配（严重）

• 日志导入违规：from astrbot import logger，应为 from astrbot.api import logger。

逻辑/健壮性

• Json2BMC() 的异常回退分支不可靠：
  • 捕获 TypeError 后使用 component_class.__fields__ 过滤参数：多数普通类/数据结构未必存在 __fields__ 属性，可能再次抛 AttributeError，导致“兜底失败”。
• ComponentTypes 中 "WechatEmoji" 键未小写；但查找时使用 data_type.lower()，因此永远匹配不到该类型（功能缺陷）。
• BMC2Text() 返回 (json字符串, type)，但上层不少逻辑把第一个值当作“可直接展示的文本”来做字符串包含判断或直接输出，这会导致输出内容变成 JSON 串、以及错误判断（协议层语义不清晰）。

性能/安全（信息泄露）

• find_tool_loop_agent_runner_with_stack_info() 会在 debug 级别打印完整调用栈文件路径与行号；在生产环境若误开 debug，可能泄露部署路径/代码结构信息，且 traceback.extract_stack() 开销较大。

---

代码评审团

人物一（Linus Torvalds，毒舌直指要害）
你这套里最致命的不是“优雅不优雅”，是基础规则都没守住：好几个文件把 logger 从 astrbot 根导入，直接违背框架约定。框架要统一日志口径不是为了好看，是为了可控。先把这些“入口级别”的一致性修好，否则后面调试就是地狱。

人物二（Grace Hopper，偏工程与可维护性）
isinstance(message, List) 这种错误非常“典型且昂贵”——它可能只在某些请求触发，然后你会在生产上收到莫名其妙的 500。建议你对外部输入（message 可能是 str/list）建立清晰的 schema 校验，并把“字符串消息”和“消息链”走两条明确分支，避免靠临时变量 messages=None/[] 这种易错状态机。

人物三（GLaDOS，冷幽默但给方案）
我喜欢你做了 SSE，但你又不完全喜欢客户端：你往队列里塞了 text_type，然后在发送端把它吃掉了。很贴心，真的。把 SSE payload 定义成稳定的结构（比如 {type, data, meta}），并确保生成端完整转发；同时给 queue.put 加超时与断连检测，不然慢客户端会把你的事件循环当人质。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 8 个 Python 文件
• 已选择审核文件: 8 / 8
  已发送至 AI 审核的文件清单

main.py
src/__init__.py
src/constants.py
src/dataclasses.py
src/http_adapter.py
src/httpmessageevent.py
src/httpsession.py
src/tool.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[Li-shi-ling]

问题好多！

[Li-shi-ling]

@astrpluginreviewer review

[astrpluginreviewer]

❌ 插件审核失败

您好！在对您的插件进行审核时遇到了问题：

调用AI审核服务时发生内部错误。

---

请根据上述问题进行修改。修改完成后，请在 Issue 正文 中勾选"重新提交审核"复选框以再次触发审核。

此消息由系统自动生成

[Li-shi-ling]

@astrpluginreviewer review

[astrpluginreviewer]

❌ 插件审核失败

您好！在对您的插件进行审核时遇到了问题：

调用AI审核服务时发生内部错误。

---

请根据上述问题进行修改。修改完成后，请在 Issue 正文 中勾选"重新提交审核"复选框以再次触发审核。

此消息由系统自动生成

[Li-shi-ling]

@astrpluginreviewer review

[astrpluginreviewer]

❌ 插件审核失败

您好！在对您的插件进行审核时遇到了问题：

调用AI审核服务时发生内部错误。

---

请根据上述问题进行修改。修改完成后，请在 Issue 正文 中勾选"重新提交审核"复选框以再次触发审核。

此消息由系统自动生成

[Li-shi-ling]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_httpadapter

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 平台适配器重复注册风险（逻辑缺陷）
   __init__ 中每次实例化插件都会调用 register_414() 或 register_416()，缺少“已注册”保护。若插件被重复加载/热重载，可能出现重复注册、覆盖或框架侧异常。

2. 命令方法命名可读性差（可维护性）
   inithttpadapter 通过 @http.command("ghp") 暴露，ghp 与功能“初始化并扫描 HTTPAdapter 实例”语义弱，后期维护和协作理解成本较高。

3. 条件表达式可读性较差（可维护性）
   other_message 中存在多层否定逻辑：
   if not (not event.get_has_send_oper() and event.is_at_or_wake_command and not event.call_llm):
   该写法容易引入维护期误判，建议重构为正向语义变量。

---

src/http_adapter.py

1. make_response 使用方式错误（功能性错误）
   options_handler 中 response = make_response('') 在 Quart 异步语境下应为 await 形式（否则可能得到协程对象而非响应对象），后续 response.status_code 可能触发运行时错误。

2. 会话管理功能未闭环（逻辑缺陷）
   声明了 self.sessions、会话清理、会话统计和删除接口，但在消息处理路径中未看到会话创建/更新（如 last_active、message_count）。导致 /sessions、/stats 数据失真，max_sessions 也无法实际生效。

3. 配置项未实际生效（实现不完整）
   至少以下配置未被使用：request_timeout、max_request_size。这会造成“配置可见但行为无效”的问题。

4. send_by_session 未实现（功能缺失）
   作为平台适配器关键能力，该方法当前 pass，会导致基于 session 的主动发送或框架调用路径失效。

5. 异常信息直接回传客户端（安全问题）
   多处返回 {"error": f"内部服务器错误: {str(e)}"}，会把内部异常细节暴露给外部请求方，增加信息泄露风险。

6. 鉴权 token 比较未使用常量时间比较（安全最佳实践不足）
   _check_auth 里 token != self.auth_token 为普通字符串比较。对于鉴权敏感值，建议使用常量时间比较方式降低时序侧信道风险。

7. SSE 结束阶段潜在阻塞（异步风险）
   _handle_http_stream_message 的 finally 中 await queue.put(None) 未设置超时；在队列满时可导致连接清理阶段阻塞。

8. health 接口无鉴权（安全暴露面）
   /health 默认公开，返回会话数、待处理数、服务信息。若部署在公网会造成运行状态暴露。

---

src/httpmessageevent.py

1. 流式结束信号可能重复发送（逻辑错误）
   StreamHTTPMessageEvent.send_streaming() 在末尾已可能调用 send_end_signal()；而插件层 on_llm_response/other_message 也会触发结束信号，存在重复 END 事件风险，影响客户端状态机。

2. queue_put_generator 返回值语义无效（代码质量/逻辑）
   方法始终 return False，但调用方先赋值给 _finalcall 后又强制设为 True，前一次赋值完全无意义，容易误导维护者。

3. 流式聚合路径内存风险（潜在性能问题）
   StandardHTTPMessageEvent.send_streaming() 将所有分片先收集到 collected_chains 再合并，长响应会产生不必要内存峰值。

---

src/httpsession.py

1. 会话状态缺乏更新入口（功能实现不足）
   类内没有更新 last_active、message_count 的方法；若外部未额外维护，会话活跃判断与统计长期不准确。

---

src/tool.py

1. 类型注解错误（代码质量）
   BMC2Dict 声明返回 tuple[str, str]，但实际第一项是 data.toDict()（字典），这会误导类型检查和调用方。

2. 常量命名不符合惯例（可维护性）
   ComponentTypes 作为模块级常量建议采用全大写（如 COMPONENT_TYPES），当前命名不符合常见 PEP 8 习惯。

---

代码评审团

人物一：Linus Torvalds（直给型）
你这套 HTTP 适配器“看起来功能很多”，但 send_by_session = pass 这种核心接口空着，等于把发动机盖上了却没装活塞。建议先把关键路径做完整，再堆外围接口。

人物二：Steve Jobs（产品体验导向）
接口配置项很多，但 request_timeout/max_request_size 没真正执行，这会让用户以为自己“掌控了系统”，实际上没有。产品最怕“看起来可配，实际上无效”。

人物三：Tony Stark（工程效率派）
流式 END 信号发两次这类问题，最容易把前端客户端状态机搞炸。建议你定义明确的“结束信号唯一发送者”，把责任收敛到一处，系统稳定性会立刻上一个台阶。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 8 个 Python 文件
• 已选择审核文件: 8 / 8
  已发送至 AI 审核的文件清单

main.py
src/__init__.py
src/constants.py
src/dataclasses.py
src/http_adapter.py
src/httpmessageevent.py
src/httpsession.py
src/tool.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[Li-shi-ling]

苦压希
问题好多

[Li-shi-ling]

src/httpmessageevent.py
1.流式结束信号可能重复发送（逻辑错误）

event.setfinalcall()方法不是立马执行的，而是延迟
所以不会直接出现两次发送关闭信号的情况