设计评审

本页整理旧 docs/DESIGN_REVIEW.md 的结论，用于帮助后续开发在做大改动前先看清系统的约束、风险和评审关注点。

评审关注什么

旧设计评审最关心的不是代码风格，而是：

系统边界是否清晰
是否存在单点脆弱性
可观测性够不够
是否有可预见的扩展风险

这对当前项目意味着什么

在 SoulBrowser 里，最容易出问题的改动通常集中在：

session / task / runtime 之间的契约
tool 执行与验证逻辑
agent prompt 与上下文注入
前端运行态状态源设计

评审时建议固定问的问题

这个改动增加了新的事实源吗
是否引入了前后端契约漂移
失败时能否被 UI 或日志明确看见
是否会把简单链路变成多源并行链路
是否让安全边界更难验证

与对话上下文增强的关系

旧 CONVERSATION_CONTEXT 文档表明，很多“智能体验问题”其实会反过来影响系统设计：

历史注入方式不对，会影响 prompt 安全
指代消解不稳，会影响任务可重复性
结果缓存不合理，会污染后续执行

所以这类设计也应进入评审，而不是只当产品细节。

相关页面