执行 Agent 上线全景架构与问题清单
结论：现有项目已经完成业务样机验证，沉淀了剧本、话术、bad case 和评分经验；下一步建议先收敛问答助手，同时单独建设生产级 Agent 主线。
附页：关键问题答疑 默认隐藏，需要时展开查看 20 个细项
这部分把你最开始问的 6 个问题和我补充的 14 个问题合并到一起。阅读方式很简单：每章先看“业务结论”，再看“现在是什么样”，最后看“应该怎么落到需求池”。技术名词只保留必要的边界词，核心用业务逻辑讲清楚。
1. 执行 Agent 和测试环境到底要不要拆？
要拆，而且这是上线主线
业务结论：现在更像“沙盘里长出了一个会干活的 Agent”，不是“我们的业务后端在调用一个独立 Agent Runtime”。如果月底要接真实业务，必须先把业务执行后端、pi Runtime、沙盘测试环境拆清楚。
新增“业务后端接 pi Runtime”P0，不再继续只优化沙盘页面。
沙盘不能直接摸执行内部状态，只能像真实环境一样提交一轮业务事件。
如果不拆，月底上线会变成把内部测试工具包装成生产系统。
2. 每个会话和外界的输入输出现在是什么逻辑？应该怎么设计？
现在是沙盘会话，不是真实业务会话
业务结论：当前会话的外部输入只有“开始跑一个剧本、查询进度、停止”。真正的客户和达人消息不是从外部系统进来的，而是沙盘内部模拟出来的。输出也不是发到真实群里，而是变成页面日志和历史记录。
任务、群、用户、消息、附件、当前业务状态、允许动作。
回复内容、文件动作、阶段动作、是否需要人工确认。
是否真的发出、外部消息编号、失败原因、是否需要重试。
3. 之前跑过的剧本怎么变成可观测回归测试？
材料有了，但还不是上线门禁
业务结论：现在有不少真实案例沉淀成剧本，也能跑出结果和评分。但它更像案例库，不是严格的回归测试。团队要判断“这一版能不能上线”时，不能只回答“跑过几个剧本”。
- 核心流程：正常寄样、脚本、拍摄、发布、结案能跑通。
- 坏案例：客户临时改需求、达人拖延、文件没给全、跨群信息漏同步。
- 边界场景：空文件、重复文件、阶段提前、等待过久、多人并发。
- 上线门禁：不要只看 AI 分数，要看“有没有做错动作”。
4. 多任务并行能不能放在同一个上下文里？
不能，共用上下文会串单
业务结论：多个商单可以共用同一套业务后端和 pi Runtime，但不能共用同一份记忆。每个商单都应该有自己的消息、文件、阶段、动作记录和失败记录。
一套业务后端 + pi Runtime 可以同时处理多个任务。
商单 A 的文件、阶段和客户要求不能被商单 B 看见。
每个任务打开后，都能看到自己独立的进度和动作历史。
5. 多任务同时执行时，环境隔离怎么做？
沙盘有初步隔离，生产隔离还没成型
业务结论：现在能做到“多个沙盘运行别互相覆盖”。但真实上线要解决的是“多个真实客户、多个真实群、多个真实文件、多个真实动作别互相串”。这是更高一层的隔离。
6. 现在上下文管理是什么，Agent 是一直在线还是每轮重新判断？
业务状态在项目里，模型每轮重新看材料
业务结论：模型本身不是一直开着一个长会话。项目会保存消息、记忆、当前阶段、文件状态；每来一轮，再把这些材料整理给模型，让它判断下一步。
7. 我们的业务后端和 pi Agent Runtime 各负责什么？
现在混在一起，产品边界应该重新画清楚
业务结论：我们的业务后端才是执行闭环的主人：接真实世界、整理业务上下文、管权限、落动作、记回执。pi Agent Runtime 不是业务后端，它负责把“当前材料 + 可用工具”跑成一次 Agent 决策。沙盘只负责测试，不负责生产执行。
接真实消息、查业务状态、管文件权限、组装上下文、执行发消息/转文件/改状态、记录回执。
拿到业务后端给的当前材料和工具说明后，跑 Agent 推理，输出结构化动作计划。
模拟客户和达人，制造案例压力，用同一入口验证业务后端 + pi Runtime 是否靠谱。
- 需求池 P0：定义业务后端到 pi Runtime 的调用契约、动作计划格式、动作回执和任务状态存储。
- 沙盘改造：沙盘以后也走业务后端入口，不再直接绑执行内部实现。
- 上线目标：真实环境和测试环境只换输入源，业务后端和 pi Runtime 的主链路不换。
8. 动作成功性现在怎么判断？
现在知道沙盘里做了什么，不知道真实外部是否成功
业务结论：Agent 说“我会发给达人”不等于消息真的发出去了。生产里每个动作都要有回执：成功、失败、失败原因、能不能重试、是否需要人工接管。
要拿到真实外部消息编号。
要确认文件存在、权限允许、目标真的收到。
要确认业务系统状态真的更新。
9. 文件可见性和权限怎么接真实环境？
业务结论：文件权限不能交给模型猜。模型只能看到“当前任务、当前群、当前身份允许看到的文件”。真正转发前，后端还要再做一次权限判断。
10. 沙盘的“上帝视角”会不会污染 Agent？
会，这是测试转生产最容易踩的坑
业务结论：沙盘知道剧本、未来事件、评分点、导演意图，但真实 Agent 不应该知道这些。如果这些信息混进业务后端给 pi 的上下文里，测试会显得很聪明，上线就会失真。
未来剧情、评分答案、导演意图、未释放的私有文件。
真实对话、真实可见文件、当前业务状态、已授权知识。
沙盘跑分时检查输入里有没有偷带答案。
11. 进程重启后任务能恢复吗？
现在还不够
业务结论：沙盘更像“跑完后保存记录”。真实商单可能跑几天，服务重启、模型超时、外部接口失败都要能继续。上线前必须把任务状态从内存里搬到可恢复存储里。
- 每轮输入要保存。
- 每次模型决策要保存。
- 每个外部动作和回执要保存。
- 恢复时要知道下一步从哪里继续。
12. 现在的评测能不能当上线门禁？
不能单独当门禁
业务结论：现在评测能帮助看趋势，但不能独立证明“可以上线”。上线门禁要回答的是：这版有没有比上版退步，有没有做错危险动作，真实动作有没有回执。
同一批剧本每次都跑。
禁止提前推进、禁止乱转文件、禁止漏同步关键事。
不是看单次分数，而是看趋势和退化。
13. 现在有哪些观测能力，缺什么？
业务结论：沙盘复盘能力已经有基础，能看日志、模型调用、历史记录。但生产观测还缺一条从真实消息到真实回执的完整链路。
14. 现在的服务面能不能直接上线？
不建议直接作为生产服务暴露
业务结论：现在一个服务里混着沙盘启动、剧本管理、历史删除、评分、模型明细查看、本地工具。这是内部平台形态，不是面向真实业务的生产运行时。
只处理真实任务输入、状态查询、动作回执。
剧本、评分、调试、删除留在内网管理面。
鉴权、脱敏、限流、审计必须先补。
15. 数据库启动逻辑有什么上线风险？
生产服务启动不应该顺手改库
业务结论：内部工具启动时顺手建表、回填、修结构还能接受；生产运行时不行。上线服务启动应该只检查依赖是否可用，不应该做迁移、删旧表或大规模回填。
- 迁移和回填要变成独立发布步骤。
- 启动失败要可预期，不要边启动边改状态。
- 回滚时要知道数据库版本和服务版本是否匹配。
16. 真实环境第一版应该接多深？
业务结论：第一版别做“大而全自动托管”。先证明一件事：真实消息能进来，Agent 能判断，动作能被外部执行，失败能查清并接管。
17. 人工审核应该放在哪里？
业务结论：人工审核不要放进模型脑子里。pi 只给出建议动作，真正执行前由业务后端动作层按规则判断：直接执行、拦截、排队人工确认，或者只生成建议。
常规同步、简单确认，可以自动执行。
文件转发、阶段推进，可以先做规则拦截。
对外承诺、合同/费用/敏感资料，必须人工确认。
18. 需求池应该怎么分 P0/P1/P2？
业务结论：P0 解决“能不能可控上线”，P1 解决“上线后能不能运维”，P2 再做体验和能力扩展。
资产定界、生产控制面契约、动作计划协议、动作回执和最小 benchmark 门禁。
真实输入输出小闭环、人工审核台、失败队列、任务恢复、版本对比。
复杂业务写入、自动结案、长期记忆优化、多模型路由、运营面板。
19. 月底交付应该怎么切？
业务结论：月底不要承诺完整生产 Agent，应该承诺三个可验收交付：资产定界、架构契约、最小 benchmark。这样既保住已有投入，也不给真实上线背过量承诺。
20. 最低上线成功标准是什么？
业务结论：最低标准不是“Agent 能聊天”，而是“出了问题能知道为什么，危险动作能拦住，坏版本能回滚”。
- 一条真实业务消息能进入业务后端，并触发一次 pi Runtime 决策。
- pi Runtime 只能看到业务后端裁剪过的授权上下文。
- 输出是明确动作，不是散文式建议。
- 外部动作执行后有回执。
- 全链路可追踪，失败可人工接管。
- 固定回归测试能对比版本退化。