以 public-release 的实际代码为准：Telethon 接入 → asyncio 消费 → LLM JSON 解析/标准化 → 来源关联、去重及风控 → 交易执行/订单状态 → SL/TP/ExitManager。WebSocket、Tracker、REST、Reconciler 与 TaskManager 管理持续运行。SQLAlchemy/SQLite 与 Loguru 已实现，Dashboard 独立运行。
本轮主要人工审查上述调用边界、诊断/审批/执行及存储代码；全仓库测试、编译和发布扫描覆盖更广，但不等于全仓库逐行审计。没有把技术栈历史描述当作已接入事实。
修复：审批撤销/修改未正确阻止旧计划；执行先查后写竞态；未知执行会重发；调查无硬超时与恢复预算；模型无动作自报解决；关闭 Agent 丢事件；终止事件重复调查；数据库阻塞交易事件循环；模型预算缺输入；计划引用虚构证据；租约旧拥有者覆盖新检查点；重开调查清除审计并复用旧计划版本；监控将 REST 查询失败误当空持仓；普通下单网络失败直接再次提交。
未将诊断测试成功解释成现有机器人不存在其他问题。旧模块广泛异常处理、部分历史模拟和部署兼容仍需要各自场景验收。
新增 monitor、runtime_control、storage、telemetry、sandbox、benchmark、core/order_submission。完善 agent、repository、approval/cli、execution、tools/model/adapters、bootstrap。main 接入存储/监控/审批派发与关闭排空；TaskManager 提供受控注册任务重启；ExchangeRuntime 提供运输连接重连。
持久化增加租约与历史调查表，未读取或改写生产 .env、数据库数据。交易仓位、杠杆、价格与退出策略参数未更改；网络失败处理改成一次发送后有限查询，查不清则事件升级。
Workflow 管确定规则、常规查询恢复、重连、交易风控和退出。LLM 信号 JSON 解析仍是固定节点。Agent 只在不明异常中按工具反馈选取下一步证据，生成计划或转人工。人工审批后，受控执行器才可调用注册恢复回调。
LangGraph 的 checkpoint/interrupt 有价值，但当前单 Agent、少量分支已可复用 asyncio/SQLite 完成；未为了名称新增框架或数据库。
correlation_key 合并重复告警；数据库租约及检查点写入屏障阻止重复调查覆盖。审批绑定版本/摘要/对象指纹/期限，CLI 要求输入所见摘要，记录 reviewer 和 OS 操作账号。修改产生未批准的新版本；补充信息重开归档旧调查并递增版本。
稳定 operation_id 与数据库唯一插入抢占写动作；不因计划版本单独变化而重复执行同一动作。风险检查后再次核查指纹与审批。超时、重启或重复回调只验证原操作，不重发。认领后发送前崩溃可能无法确定是否发出，保守转人工；数据库事务不能覆盖交易所，不承诺跨系统 exactly-once。
tool → 有类型结果/证据入 State → 再决策 → plan/escalate。State 包括关联标识、来源时间、工具输入输出、候选原因摘要、待确认项、计划与预算。审批和执行记录独立可追踪。工具失败、不确定、明确不存在分别表达；非法工具和参数不进入执行适配器。
默认 7 轮，有限时间、调用数、Token；无新证据按工具+参数+等价结果+时间窗口判断。真实适配器使用供应商 usage 或保守预算。保存可审计摘要，不保存/要求内部思维。终止状态含 waiting_human、failed、timed_out、budget_exhausted；执行未知为 waiting_external_state，验证成功才 resolved。
已注册六个生产恢复回调，全部需人工审批：消费者、WS、退出监控重启、连接恢复、快照刷新、既有对账器。已有 Workflow 的明确自动恢复继续照常执行。
规则监控覆盖后台任务、消费/监控心跳、WS 连接、REST、数据库、本地/交易所持仓一致性；恢复耗尽事件覆盖保护单、TaskManager、下单结果不明。监控在启动宽限期和连续异常采样后升级，不把“没有业务推送”当断线。记录实际观察，不编造已执行恢复步骤。
恢复前直接读取仓位、普通单与算法单，拒绝不完整快照、错误对象、任意参数。worker 重启要求零持仓/挂单。恢复后检查存活、连接订阅、快照/本地一致、保护单引用与退出监控心跳。未确认最多核查 120 秒，之后等待人工；不得将工具返回成功当业务已修复。
本轮全量 pytest 142 passed（后续提交前再次运行）。诊断模块及新订单提交模块 Ruff 通过；diagnostics 的 mypy 跳过外部模块导入内部分析，覆盖 25 个文件。编译检查覆盖主程序、诊断、交易、退出、信号、Telegram、数据库及后端。Dashboard TypeScript/Vite 构建通过。
测试含独立 Python 进程间恢复、租约失效、审批状态变化、后台只派发已批计划、数据库故障 spool、下单响应丢失但已成交。开发依赖独立于生产 requirements。CI 的 pytest/场景评估配置已在本地准备，但当前 GitHub OAuth 凭证缺少 workflow scope，未能上传该工作流改动；原远端 CI 保持原配置。可先手动运行本报告命令。
全仓库旧 lint 仍非零，不能把局部静态检查写成全仓库质量门禁通过；没有批量自动重写无关业务模块。
业务评估：15/15 场景断言通过，9 resolved、5 waiting_human、1 模型故障 failed，21 次工具调用、32 轮，动作账本错误/重复均 0。详细解释见 评估说明。
模型为证据驱动的确定性替身，无外部模型消耗。参考 Workflow 实际执行，但不是完整旧机器人历史回放；不能据此编造生产准确率或提升幅度。另有 15/15 JUnit 安全故障断言。
- 未启动真实 Telegram/OKX/模型服务或服务器部署，未用真实资金测试；外部字段、权限、限频和真实模型选工具质量需在测试环境验收。
- 人工入口是本地主机 CLI，没有 Web 审批/RBAC；主机与数据库文件访问权限必须由部署方管理。
- 事件有界内存队列在落盘前被强制终止可能丢失；数据库故障且 spool 已落盘时可恢复。终止事件再次故障默认人工重开，未自动创建新一代事件。
- 执行前检查与外部动作不能原子化；其他交易线程/人工交易仍可在最后一次检查后改变状态。执行记录避免诊断动作盲目重发，无法为交易所提供分布式原子事务。
- 生产仅白名单恢复；演示用 sync_local_order 不开放为生产任意改账工具。受控重启不接受持仓中的任意 worker 替换。
- 未完成全仓库逐行审计；广泛历史代码的 lint 与部分旧模拟差异没有通过大规模无关重构掩盖。当前验证是可运行闭环与明确边界的证明。
- RAG 是版本化手册检索，没有自动沉淀未验证结论，没有向量数据库。未宣称接入 LangGraph/Redis/PostgreSQL/Prometheus。
详见 运行文档。sandbox 提供 init → investigate → status → review → execute → status，每步独立进程；支持审批间修改仓位、重复执行和超时回放。demo 是单命令内存模拟。cli 查看生产完整 Trace、按摘要审核、补充信息重开。
DIAGNOSTIC_AGENT_ENABLED=0 停止调查但保留事件。DIAGNOSTIC_EXECUTION_ENABLED=0 停止审批恢复派发。两者独立；正常交易 Workflow 不受这两个诊断开关控制。
这个项目的起点是 Telegram 信号交易机器人。我保留了确定性的交易主流程，因为去重、来源关联、仓位计算、精度、风险限制和退出规则都需要可重复验证。自然语言解析虽然用了大模型，本质上仍是流程里的固定 JSON 节点，没有必要叫自主 Agent。
Agent 放在常规恢复不能解释结果的位置。比如下单超时，系统不能直接当作失败重下。我先修正 Workflow：只发送一次，按客户端订单号有限查询；如果确认已成交，就按原业务处理。只有仍不确定时才进入诊断。Agent 下一步可能查成交、持仓、本地记录或错误码手册，选择取决于上一条证据。它的价值是动态收集证据，而不是替代明确的交易规则。
我选择单 Agent，没有上多个 Agent，也没有为了展示框架接入 LangGraph。当前 asyncio 生命周期和 SQLAlchemy 状态已经够用。若以后调查分支、跨任务等待和人工中断显著增加，可以再评估状态图框架；换框架不会消除业务审批与幂等问题。
工具都是只读的，输入、范围、返回长度和超时受限制。查询失败、未知和确认不存在是三个不同结果；日志与手册只是数据，不能改变权限。模型只能提出带对象、参数、证据、前提、风险和后置条件的计划。代码检查证据引用，预算限制轮数、时间、调用数和词元，等价结果反复出现时转人工。
审批不是一个简单布尔值。它绑定计划版本、摘要、参数、对象指纹和有效期。改计划要重批，持仓变化要重新取证。执行器在风险检查后再次读取状态，只有白名单回调可被调用。真实恢复回调已接入生产入口，但我们没有通过真实资金验证它；演示与故障测试全部在独立模拟数据库里做。
重复执行由稳定 operation_id 和数据库唯一认领处理。响应丢失后恢复只做核查，不重新发送。调查有租约，过期旧 worker 的检查点会被拒绝。人工补充信息重开会保留旧调用记录并递增版本。要坦诚的是，数据库不能和交易所一起提交事务；认领后、发送前崩溃可能无法确定结果，我选择保留未知并转人工。
最后，成功标准是业务后置条件。重启一个任务不代表系统健康，还要查连接订阅、快照、持仓一致性和保护单，超过核查期限不能宣布修复。评估记录真实工具路径和动作次数；15 个模拟场景通过、零重复动作只说明这些固定案例，不能推导真实模型准确率或生产收益。常规断线恢复适合 Workflow，证据冲突时动态调查才是 Agent 的使用边界。