构建了一个 LLM 在结构上被禁止生成最终输出的 Agent，寻求反馈以及愿意尝试“攻破”它的人

在这里发帖是因为我最终确定的这种约束机制感觉有些奇特，我想知道是否有其他人做过类似的事情，或者认为我的想法有误。 **背景：** 我构建了一个用于复现生产环境 Python 崩溃的 Agent。你只需提供一个 Sentry URL，该 Agent 就会读取堆栈跟踪（stacktrace）和帧局部变量（frame locals），决定调用哪些工具（如仓库内省、依赖准备、沙箱执行等），并在 Docker 沙箱中运行所有操作。最终，它要么生成一个确定性的失败 pytest 测试（你可以直接粘贴到你的仓库中），要么在无法完全复现时提供一份结构化的调查报告。 **奇特之处：** LLM 在结构上不被允许编写最终的测试代码或审计工件（audit artifact）。这些字节数据来自一个纯确定性的 Python 函数，该函数仅以捕获的帧局部变量作为输入。Agent 可以进行规划、调用工具、从死胡同中恢复以及推理竞态条件，但当需要输出实际的测试/工件时，执行的是非 LLM 的代码路径。该工件始终标记为 llm_in_evidence_path: false。架构采用 LangGraph Supervisor 加上 11 个工具。Agent 的评估标准基于其确定性输出，而不仅仅是推理过程。 这种分离是否值得付出额外的复杂性，还是说我过度设计了？我目前大约有 800 个单元测试，但还没有真正的外部评估框架，我知道这才是真正的短板。如果你也在构建 Agent 并对这种架构有见解，我将真诚地感谢任何反馈。 另外：如果你手头有未解决的 Python Sentry 问题（尤其是涉及 Django/FastAPI/Celery/SQLAlchemy 的），我很乐意让它运行一遍，看看会发生什么。帧局部变量是关键，因此任何使用默认 Python SDK 设置的环境应该都能适用。请直接私信或留言，哪种方式方便用哪种。