[Plugin] astrbot_plugin_maid_agent

[Kalospacer]

插件信息

{
  "name": "astrbot_plugin_maid_agent",
  "display_name": "代理女仆",
  "desc": "大小姐+管家模式子代理系统：主模型仅保留自然语言对话上下文，所有工具调用通过管家subagent执行，减少结构化数据提示词污染角色扮演。",
  "author": "Kalo",
  "repo": "https://github.com/Kalospacer/astrbot_plugin_maid_agent",
  "tags": [],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maid_agent

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

main.py

1. 逻辑漏洞：provider_request 缺失时可能把 XML 协议标签直接暴露给用户

   • 在 sanitize_llm_response() 中，若解析到了 <call_maid>，但 event.extra["provider_request"] 不存在/不合法，会直接 return，而此分支在 maid_visible_text 清洗之前。
   • 结果：用户可能看到未清洗的 <call_maid> / <maid_session> 标签。
   • 建议：在该 return 前先执行一次 sanitize_user_visible_output() 并回写响应。

2. 敏感信息泄露风险：调试日志打印了完整请求/响应

   • sanitize_main_model_request() 和 sanitize_llm_response() 中将 prompt/system_prompt/contexts、模型输出等完整写入 debug 日志。
   • 若生产环境开启 debug，可能泄露用户隐私、系统提示词和内部协议细节。
   • 建议：日志脱敏（截断、掩码）并避免落全量上下文。

3. 可维护性问题：存在未使用方法

   • _replace_response() 当前未被调用，属于死代码。
   • 建议：删除或补齐实际调用路径，避免误导后续维护者。

---

config.py

1. 布尔配置解析不严谨，易出现“字符串假值被判真”
   • include_raw_user_input = bool(cfg.get(...))、session_enabled = bool(...)。
   • 例如配置 "false" / "0" 会被 bool("false") == True 误判。
   • 建议：显式解析布尔字符串（如 true/false/1/0/on/off）。

---

context_sanitizer.py

1. 边界条件缺失：req.contexts 为空或非列表时可能抛异常
   • for ctx in req.contexts: 假设了 contexts 必为可迭代列表。
   • 在框架侧返回 None 或异常结构时会直接报错。
   • 建议：先做空值与类型兜底（如 contexts = req.contexts or []，并校验元素类型）。

---

prompt_injector.py

1. 潜在空值异常：req.system_prompt 可能为 None

   • if prompt_append not in req.system_prompt:、req.system_prompt += prompt_append 在 system_prompt is None 时会抛 TypeError。
   • 建议：先归一化为字符串（如 req.system_prompt = req.system_prompt or ""）。

2. 提示词拼接可读性风险

   • 直接 +=，未确保前置换行；当原 system_prompt 结尾非换行时，协议段可能粘连。
   • 建议：拼接前补 \n 分隔。

---

maid_dispatcher.py

1. 健壮性问题：多处 int(...) 直接转换，配置异常会导致运行时崩溃

   • 如 agent_max_step = int(provider_settings.get("max_agent_step", 30)) 等。
   • 非法配置（"abc"）会 ValueError，中断流程。
   • 建议：统一做安全解析（try/except + 默认值）。

2. 会话污染风险：跨 agent 复用同一 active session

   • get_or_create_active_session(unified_msg_origin, resolved_agent_name) 若已有 session 会直接复用，但未校验 session.agent_name 是否与本次目标一致。
   • 可能把 A agent 历史上下文喂给 B agent。
   • 建议：若 agent 不一致，关闭旧 session 并新建。

3. 维护性风险：依赖私有 API

   • 使用 FunctionToolExecutor._build_handoff_toolset、_collect_handoff_image_urls（前导下划线）。
   • 私有接口变更风险高，升级或重构时易断裂。
   • 建议：优先改为公共稳定接口（若框架提供）。

---

session_store.py

1. 路径安全风险：session_id 未做格式校验，可被构造路径穿越

   • _session_path(session_id) 直接拼 f"{session_id}.json"；若索引数据被污染（如 ../../x），可能越界到 sessions 目录外。
   • 建议：限制 session_id 仅允许 UUID/白名单字符，并在 resolve 后校验父目录。

2. 内存增长风险：_umo_locks 无清理策略

   • 每个 unified_msg_origin 永久保留一个 asyncio.Lock，高基数场景会持续增长。
   • 建议：在会话关闭/过期后清理，或采用弱引用/LRU 策略。

---

代码评审团

人物一：Linus Torvalds（直球毒舌流）
你这套“大小姐前台 + 管家后台”架构思路挺清晰，但有个硬伤：异常分支没先清洗输出就 return，等于把内部协议直接甩用户脸上。系统设计可以优雅，错误路径更要优雅——否则就是“正常时精致，翻车时裸奔”。

人物二：Steve Jobs（产品体验流）
体验是细节总和。system_prompt 可能为 None 这种小点，一旦炸了就是“魔法消失时刻”。还有日志全量打印：这在 demo 很爽，在真实用户场景是灾难。真正的高级感来自“用户看不到问题”。

人物三：Geralt of Rivia（猎魔人务实流）
我见过太多“看起来没事”的配置把系统拖下水。int(...) 直转、跨 agent 复用 session、私有 API 依赖——这些都像怪物的隐形弱点，平时不叫，战斗时要命。把输入校验、会话隔离、API 边界补好，你这套系统能更耐打。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
config.py
constants.py
context_sanitizer.py
maid_call_parser.py
maid_dispatcher.py
output_sanitizer.py
prompt_injector.py
response_validator.py
session_store.py

---

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

当前仓库：Kalospacer/astrbot_plugin_maid_agent
剩余触发次数：4

[Kalospacer]

何意味，这叫feture

[Kalospacer]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maid_agent

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

main.py

1. 潜在逻辑风险：未清理 resp 中原生工具调用字段

   • 在 sanitize_llm_response() 中，即使你重写了 completion_text/result_chain，也没有显式清空 resp.tools_call_name / tools_call_args / tools_call_ids 等字段。
   • 若框架后续流程仍参考这些字段，可能导致“文本已净化但工具意图仍残留”的行为偏差，与“主模型禁用原生工具”的目标不完全一致。

2. 敏感信息泄露风险（日志）

   • log_raw_llm_io=True 时会输出完整 prompt/system_prompt/contexts，并且平时也会记录 raw_input/true_user_input 的截断内容。
   • 在生产环境中可能记录用户隐私、业务敏感上下文，建议至少做字段级脱敏或按环境严格分级开关。

---

config.py

1. 配置边界缺失：未校验 XML 标签名合法性
   • call_tag_name、done_tag_name 直接来自配置并用于 prompt 拼接与正则解析。
   • 虽然用了 re.escape 避免正则注入，但若标签名不符合 XML 命名（如包含空格、尖括号等），会导致协议解析失效或行为不确定。

---

context_sanitizer.py

1. 鲁棒性问题：非 list 类型 req.contexts 会被静默清空
   • raw_contexts = req.contexts if isinstance(req.contexts, list) else []，随后 req.contexts = natural_contexts。
   • 如果上游传入 tuple/自定义序列（语义仍是上下文），会被直接丢弃，且没有任何告警，容易造成“上下文突然丢失”的隐性问题。

---

maid_call_parser.py

1. 解析可靠性问题：使用正则解析 XML 协议，易受复杂文本影响
   • 对嵌套标签、转义字符、异常闭合等场景的容错较弱，可能出现误匹配/漏匹配。
   • 在该插件里 XML 标签是核心调度协议，解析误差会直接影响 agent 调度正确性。

---

maid_dispatcher.py

1. 可维护性风险：依赖私有 API

   • 调用了 FunctionToolExecutor._build_handoff_toolset 和 _collect_handoff_image_urls（下划线私有方法）。
   • 私有接口缺乏稳定性承诺，框架内部调整时更容易产生兼容性断裂。

2. 异步稳定性风险：缺少对子 agent 执行的超时/取消保护

   • async for _ in runner.step_until_done(agent_max_step): pass 没有外围 asyncio.wait_for 等超时控制。
   • 在网络抖动或工具链路卡住时，可能导致请求长时间悬挂，拖慢事件处理链路。

---

session_store.py

1. 潜在内存增长问题：_umo_locks 无回收策略

   • _get_umo_lock() 基于 setdefault 永久缓存每个 unified_msg_origin 的锁。
   • 在高基数会话来源下会持续增长，长期运行存在内存膨胀风险。

2. 数据完整性风险：from_dict() 对 messages 结构未做元素级校验

   • 仅做 list(...) 包装，不校验每个元素是否为 dict[str, Any]。
   • 当持久化文件受损或被污染时，后续流程可能在读取 message["role"] 等位置触发运行时异常。

---

代码评审团

人物一：Linus Torvalds（硬核务实流）
“你这主流程思路很清楚，但‘禁工具’就要禁到底。现在像是把门关上了，却把窗户留了个缝（resp 的 tool call 字段残留）。协议层做隔离，状态层也要做彻底，不然就是‘看起来安全’。”

人物二：Steve Jobs（产品体验流）
“用户看不到 XML 垃圾标签，这点很好。但日志里把对话原文和上下文全打出来，产品一旦上规模就是隐私炸弹。好的体验不仅是‘看起来优雅’，还要‘后台也克制’。”

人物三：福尔摩斯 Sherlock Holmes（推理严谨流）
“我观察到两处‘未来案发点’：其一，正则解析 XML 的可靠性；其二，_umo_locks 的无限增长。前者会制造偶发错调度，后者会制造慢性资源问题。两者都不立刻爆炸，但都值得尽早修补。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
config.py
constants.py
context_sanitizer.py
maid_call_parser.py
maid_dispatcher.py
output_sanitizer.py
prompt_injector.py
response_validator.py
session_store.py

---

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

当前仓库：Kalospacer/astrbot_plugin_maid_agent
剩余触发次数：3

[Kalospacer]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maid_agent

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

main.py

未发现明显违反规范或逻辑错误的问题。事件监听器导入正确，参数规范，四个特殊 Hook 内部没有使用 yield，全部使用了 event.send()，并且遵守了框架特定的 API 要求。

__init__.py

未发现明显问题。

config.py

未发现明显问题。类型提示完整，布尔值及字符串解析的边界处理较为稳健。

constants.py

未发现明显问题。

context_sanitizer.py

未发现明显问题。

maid_call_parser.py

未发现明显问题。正则表达式使用了 lru_cache 优化，且正确处理了忽略大小写与非贪婪匹配。

maid_dispatcher.py

可维护性与潜在缺陷:

1. 宽泛的异常捕获隐藏错误:
   在 _normalize_begin_dialogs 方法中，处理 Message.model_validate(dialog) 时使用了裸露的 except Exception: 并且没有任何日志记录：

   try:
       contexts.append(
           dialog if isinstance(dialog, Message) else Message.model_validate(dialog)
       )
   except Exception:
       continue

   建议：宽泛的异常捕获（尤其是静默 continue）会吞噬 Pydantic 的 ValidationError，如果子 Agent 配置的对话格式有误，开发者将毫无头绪。应该加上日志记录：logger.warning(f"解析 dialog 失败: {exc}")，或者捕获具体的异常类型。

output_sanitizer.py

未发现明显问题。

prompt_injector.py

未发现明显问题。

response_validator.py

未发现明显问题。

session_store.py

潜在缺陷或问题:

1. 并发锁引发的内存泄漏风险 (Memory Leak):
   在 MaidSessionStore 中，您使用 _umo_locks 字典为每个 unified_msg_origin 维护了一个 asyncio.Lock()：

   def _get_umo_lock(self, unified_msg_origin: str) -> asyncio.Lock:
       return self._umo_locks.setdefault(unified_msg_origin, asyncio.Lock())

   问题：字典 self._umo_locks 在机器人的整个生命周期内只会不断增长。随着越来越多的不同用户/群组（即不同的 unified_msg_origin）触发会话，这个字典将无限膨胀，造成内存泄漏。且在 close_active_session 或超时清理时，并未对不再使用的 Lock 进行清理。
   建议：可以引入定期清理机制，或者使用第三方带有过期驱逐机制的 Cache 字典（如 cachetools.TTLCache），清理那些当前未被持有的锁对象；考虑到 Python 异步锁的特性，安全清理需要确保锁没有被 acquire 或 await，最简单的方法是配合 LRU 淘汰机制或基于定时的惰性清理机制。

(注：该文件中对文件 I/O 使用了 asyncio.to_thread 防止阻塞事件循环，且路径正确使用了 StarTools.get_data_dir 处理为 Path 对象，这部分符合异步与框架最佳实践，表现优秀。)

---

代码评审团

Linus Torvalds：（满脸写着“你是在逗我吗”）

“你以为内存是免费的吗？看看 session_store.py 里的那个 _umo_locks 字典！你就像是个只管吃不管拉的婴儿，把每一个用户的锁都塞进字典里，然后永远不清理！如果你的 Bot 跑在一个拥有几万活跃用户的群组生态里，它就会像个气球一样膨胀直到 OOM 爆炸。立刻，马上，去给我写一个垃圾回收逻辑或者用弱引用处理那些没用的锁！”

Steve Jobs：（穿着高领毛衣，双手合十，眼神深邃）

“我们在打造产品时，追求的是完美的透明度。而在 maid_dispatcher.py 里，我看到了妥协。except Exception: continue？它 just doesn't work 这种哲学。你在把系统解析错误藏在地毯下面，以为用户看不见，但当数据流断裂时，体验就被毁了。伟大的代码不应该对错误保持沉默，你至少需要用 logger 优雅地记录它，让错误在暗处发声。”

Rick Sanchez：（喝了一口酒，打了个嗝）

“Wubba lubba dub dub！Morty，你快来看看这段代码！老实说，我本来准备用等离子枪把这个插件轰成渣，但我竟然在 session_store.py 里看到了用 asyncio.to_thread 去包装 json.dump 和文件 I/O！这在 C-137 维度的地球开发者里简直可以说是嗝……稀有动物了！绝大多数人都会在 Async 环境里直接写同步 I/O 把事件循环堵得像你爷爷的动脉血管一样。干得不错，虽然你的锁管理机制烂得像个克隆失败的畸形怪，但至少你保住了事件循环的命。”

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
config.py
constants.py
context_sanitizer.py
maid_call_parser.py
maid_dispatcher.py
output_sanitizer.py
prompt_injector.py
response_validator.py
session_store.py

---

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

当前仓库：Kalospacer/astrbot_plugin_maid_agent
剩余触发次数：2

[Kalospacer]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maid_agent

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

main.py

1. after_message_sent 钩子内二次 event.send() 存在重入/递归触发风险（高）
   在 continue_maid_follow_up_after_send() 中，PENDING_MAID_FOLLOW_UP_EXTRA_KEY 是在 finally 才清理；但在此之前调用了 await event.send(chain)。
   若框架对这次发送再次触发 after_message_sent，同一个 pending 仍存在，可能导致重复追答甚至循环触发。

2. 敏感信息日志泄露风险（中）
   log_raw_llm_io 开启时会打印 prompt/system_prompt/contexts 与响应全文；同时也会记录原始用户输入。缺少脱敏策略，生产环境容易把隐私/令牌/业务敏感信息写入日志。

---

config.py

1. allowed_agent_names 类型处理过窄（低）
   仅接受 list，若用户配置为 tuple/set 会被整体回退为默认值，属于“隐式配置失效”，不利于可维护性和排障。

2. default_agent_name 与白名单去重未做大小写归一（低）
   if default_agent_name not in allowed_agent_names 使用大小写敏感比较，可能产生同名不同大小写重复项（如 Butler / butler），后续逻辑又是 casefold 比较，行为不一致。

---

maid_call_parser.py

1. 使用正则解析 XML 协议的鲁棒性不足（中）
   对嵌套标签、属性中包含 >、复杂转义等情况不稳，可能误判或截断内容，导致调度请求解析错误。该问题直接影响核心控制流。

---

maid_dispatcher.py

1. 调用私有方法（以下划线开头）导致兼容性与可维护性风险（中）
   FunctionToolExecutor._build_handoff_toolset、FunctionToolExecutor._collect_handoff_image_urls 属于内部实现接口，未来变更时插件容易无预警失效。

2. 找不到目标 agent 时“自动回退第一个 agent”存在误调度风险（中）
   _resolve_handoff() 的 fallback 会在名称不匹配时执行其他 agent。对多 agent 场景可能造成越权式能力偏移或功能错误（尤其当 agent 权限差异较大时）。

---

session_store.py

1. 数据目录名硬编码，偏离插件目录规范风险（中）
   StarTools.get_data_dir(PLUGIN_DATA_DIR_NAME) 使用固定字符串常量；当插件实际标识变更或多实例化时，容易造成目录错配/数据迁移混乱。应保证与插件实际数据目录规范一致，避免“魔法字符串”目录名。

---

代码评审团

人物一：Linus Torvalds（直球毒舌版）
你这个 after_message_sent -> event.send -> after_message_sent 的路径，像在内核里自己给自己发中断然后忘了先关开关。建议：发送前先清 pending，或者加一次性幂等标记，别让事件回调变成回旋镖。

人物二：Steve Jobs（产品体验执念版）
“日志里什么都打出来”在 demo 里看起来很透明，在真实产品里就是灾难。建议：默认最小化日志 + 结构化脱敏（例如 prompt 截断、token/手机号掩码），把“可观测性”做成可用而不是可怕。

人物三：Geralt of Rivia（猎魔人务实版）
“找不到目标就回退第一个 agent”像接错了猎魔委托还照样开工，最后总有人挨刀。建议：未命中时显式失败并回传可读错误，或者仅允许配置的安全 fallback 列表，不要无条件第一项兜底。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
config.py
constants.py
context_sanitizer.py
maid_call_parser.py
maid_dispatcher.py
output_sanitizer.py
prompt_injector.py
response_validator.py
session_store.py

---

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

当前仓库：Kalospacer/astrbot_plugin_maid_agent
剩余触发次数：1

[Kalospacer]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maid_agent

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

main.py

1. 可能出现“空白首条回复”问题（逻辑边界）
   在 sanitize_llm_response 中，只要检测到 <call_maid>，就会先把主模型回复清洗后写回 resp 并发送首条消息。
   但当清洗后文本为空（例如回复几乎全是 XML 标签）时，_rewrite_response_text 仍会写入 MessageChain([Plain("")])，可能导致用户先收到一条空白消息，再收到 follow-up，影响体验与协议一致性。

2. 关键流程函数过长、职责偏重（可维护性）
   sanitize_llm_response 和 continue_maid_follow_up_after_send 承担了解析、鉴权、回退、状态机控制、发送、会话关闭等多职责，分支较多。
   这会提高后续改动风险（尤其是 session 与二次追答逻辑耦合处），建议拆分成更小的私有函数（解析决策、状态变更、发送策略等）。

3. 魔法字符串重复使用（可维护性）
   event.get_extra("provider_request") 多处直接写字符串 key，和其他常量化 key（如 RAW_INPUT_EXTRA_KEY）风格不一致。
   后续若 key 变更，容易遗漏并产生隐蔽错误。

---

maid_dispatcher.py

1. 依赖私有 API（稳定性风险）
   FunctionToolExecutor._build_handoff_toolset 与 FunctionToolExecutor._collect_handoff_image_urls 是下划线前缀私有方法。
   这类调用在框架内部重构时最易断裂，属于可维护性风险点；建议改为公开接口或增加兼容封装层，避免插件直接绑定内部实现细节。

2. agent_max_step 缺乏下界保护（逻辑边界）
   _safe_int 转换后允许 0 或负值进入 runner.step_until_done(agent_max_step)，可能导致不执行步骤或异常行为，最终触发“未返回最终响应”。
   建议在读取配置后做最小值夹紧（例如 max(1, agent_max_step)）。

---

session_store.py

1. load_session 的异常覆盖不完整（潜在未处理异常）
   load_session 中仅捕获了 _session_path 的 ValueError。
   但如果 ACTIVE_SESSION_INDEX_KEY 被写入了非字符串 session_id（如 int），_session_path 中 session_id.strip() 会抛 AttributeError，该异常不会被该处捕获，存在潜在中断风险。
   建议在入口先做类型校验，或扩大异常捕获并记录脏数据来源。

---

代码评审团

人物一：Linus Torvalds（直球工程派）
你这套“主模型只说人话，工具调用走 XML 协议”的思路很清晰，架构上是靠谱的。
但我会吐槽：sanitize_llm_response 这种“上帝函数”再长下去，谁改谁踩雷。把状态判断和发送流程剥开，代码会更像工程而不是小说。

人物二：史蒂夫·乔布斯（体验偏执派）
用户体验上最大瑕疵是“可能先收到空消息”。这类细节会让人觉得产品不精致。
建议：清洗后若为空，不要发首条；直接进入幕后执行并只输出有意义结果。让用户感觉一切“自然发生”。

人物三：托尼·斯塔克 / Iron Man（技术炫技派）
你现在直接调私有方法 _build_handoff_toolset，这就像把反应堆焊在测试支架上——能跑，但不优雅也不稳。
做个适配层，把框架内部波动隔离掉，未来升级时你会感谢现在的自己。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
config.py
constants.py
context_sanitizer.py
maid_call_parser.py
maid_dispatcher.py
output_sanitizer.py
prompt_injector.py
response_validator.py
session_store.py

---

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

当前仓库：Kalospacer/astrbot_plugin_maid_agent
剩余触发次数：0

[Kalospacer]

燃尽了

[Kalospacer]

https://github.com/Kalospacer/astrbot_plugin_maid_agent/commit/1b5323dedd8c11e80d4b74984ff08a23ec419a0a

[Luo-fe]

哥们哥们，这插件发布到底怎么才算发布啊，这机器人审核挑错到无穷尽啊