BriefLoop 0.21.0：面向持续报告工作的本地研究、修订与证据追溯系统

工程技术报告 · 预发布稿 v2 · 2026 年 9 月 14 日

本文说明 BriefLoop 如何把用户提供的资料和报告要求，转化为可编辑、带来源依据的报告及 Word 文件，以及如何接回修改、核查问题并服务下一期报告。

版本身份。 本文固定读取 codex/deep-research-0210 的开发工作树：基线提交 17c43de3755dabff47895828d4ab331c99e340a0，叠加取证时尚未提交的 0.21.0 改动。619 个文件的路径与内容哈希集合摘要为 6637862988e0e7441b391773032cd00215bb1e5005115b69513171cb255c5e94。这份副本可以复核本文描述，但不是正式发行提交。并行维护分支中的可靠性修复与原生验收，只有在最终集成后才可纳入 0.21.0 的发行结论。

摘要

BriefLoop 是一个在本机运行的 AI 研究与报告工作台，面向需要反复制作行业周报、公司跟踪、经营简报或会议纪要的人。用户添加公告、研报、表格、会议笔记等材料，说明报告给谁看、要回答什么问题，并选择通用或自己的 Word 模板。BriefLoop 调用用户配置的 AI 宿主读取资料，在获准时搜索补充材料，组织分析，生成可在网页修改、包含表格和图表的报告，再导出为 Word。

这份工作可以接着做下去：用户能查看结论对应的材料，在网页改稿，或导入 Word／WPS 修改后的文档；系统保留各版正文、来源和核查记录，帮助识别修改后哪些结论需要重新检查。初稿可以先阅读和下载，正式交付另行检查重要事实与未决冲突。下一期可继续使用模板、明确偏好和经过比较后采纳的写作经验，用于减少重新交代要求与整理材料的重复劳动。

0.21.0 的主要新增工作是让用户选择快速、标准或深度研究，并将这一选择保存到任务中。深度研究围绕已有发现和剩余问题分轮推进，每轮保留来源交接和预算记录。本文解释这条报告生产路径的实现、权限与版本规则，并列出已有验证和发行前仍需完成的验收。本地工作区负责保存资料与产物；实际使用的云端模型、搜索和连接器仍可能接收任务材料。

1. 从一次回答到持续报告

行业周报、公司跟踪和管理层简报往往同时包含本期来源、历史写作习惯、稳定企业背景和读者临时要求。它们用途不同。例如，历史报告可以约束主章节和措辞密度；本期公告可以支持事实；企业背景可以帮助判断哪些变化值得关注。把三者作为一段无差别上下文交给模型，容易把旧事实带入新稿，或把格式偏好误当成当期证据。

BriefLoop 将一次报告建模为 run。任务保存读者、用途、时间窗口、篇幅、必答问题、人工填写章节、选定来源和内容方法。生成、评价、修订、学习和 Word 制作分别通过作业记录执行。作业是否结束与稿件是否存在是两个状态：后续评价失败时，已经接纳的初稿仍有自己的版本身份。E01

以“根据公告与历史周报，更新本周公司跟踪报告”为例，系统需要完成四次交接。先把用户要求整理成可执行的报告约定；再把搜索结果变为已保存、可定位的来源；随后把分析写入可编辑正文，并保留主张与依据关系；最后对用户选定版本进行核查和制作 Word。下一期报告可以复用模板与已采纳经验，但必须重新建立当期事实依据。

系统因此围绕“这份报告及其历史”组织工作，而非围绕一段聊天的最终回复。用户可以从 WebUI、桌面窗口或外部 Agent 入口进入；这些入口复用同一套工作区业务对象。

1.1 架构定位：为什么在现有研究工具与 Skill 之外维护报告状态

已有的研究工具和 CLI Skill 能完成相当多的报告工作。对一次性资料整理，用户在熟悉的宿主中提供材料、写作规范和模板，就可能得到足够好的结果。BriefLoop 增加工程机制的理由，来自持续使用中的具体交接：分析师改过正文以后，原来的核查还适用吗？来源发布更正以后，哪份稿件受影响？两位使用者同时保存或下载时，文件对应哪一版？下一期采用的经验，究竟来自哪次修改？这些问题要求应用持续保存并检查状态。

Skill 描述研究步骤、写作标准与工具用法，CLI 宿主提供执行能力和权限。Skill 可以调用脚本计算哈希、检查数字、保存版本或转换 Word；这些能力并非 BriefLoop 独有。一份纯文字规范本身不建立数据库事务、版本接纳和进程隔离，相关保证来自宿主与实际执行的程序。若将这些程序、状态和界面组装起来，也是在建设应用层。BriefLoop 提供的就是针对持续报告预先接好的这一层，且仍使用宿主和 Skill 完成研究与写作。

通用 Deep Research 项目也不能归为“搜索后吐出不可编辑文本”：STORM／Co-STORM 支持多视角提问与人机协作探索；GPT‑Researcher 提供本地材料研究、多 Agent 路径及 Word 等导出；OpenAI Deep Research 支持研究计划调整、过程引导、后续迭代和 Word 下载。下表比较实现职责与选型时需要核对的问题，不对这些产品未逐项审计的能力作缺失判断。STORM 官方仓库、GPT‑Researcher 官方仓库、OpenAI 使用说明。检索日期与范围见 E31。

BriefLoop 列的实现证据分别见第 2、6、7、8 节。这里的确定性指“程序按保存的输入与规则处理状态”：过期 base_version 不能覆盖新稿，旧版本核查不能替新正文背书，同一导出应读取确定的文档与资源。证据是否充分、行业推论是否合理仍需判断；代码不能保证报告事实永远正确，也不能赋予材料法律证明力。

因此，增加模块应有可检验的收益：版本检查防止改稿覆盖，绑定检查防止用旧审阅交付新稿，离线审计包方便交接，导入对齐减少外部改稿后的重新整理。如果任务只需一次性长文且没有这些交接，直接使用既有研究工具或 Skill 更简便。若用户持续改稿、追踪来源更正并复用周报，统一这些状态才有价值。它是否足以抵消部署和维护成本，应由完成报告所需人工时间、误报与返工数量验证；本报告尚无证明优于上述工具的对照实验。

2. 架构与职责

本地服务接收界面与外部客户端请求，通过 SQLite Store 保存结构化状态，通过工作区文件保存原件、图表、任务产物和导出文件。Worker 从作业记录中执行工作，运行时适配层负责调用实际 CLI 或模型宿主。前端展示的是持久化作业和稿件状态，而不应把模型的一句“完成”直接当成工件已经保存。

运行时适配具体包括 Codex app-server、OpenCode Server，以及处理 ACP 或流式 JSON 的 Node 桥接层。桥接把不同宿主的文本、工具进度、许可问题和结束状态转换为共用事件，同时保留宿主会话身份。当前取证副本的目录有 27 项，但目录负责发现与配置，不意味着 27 项均有完整报告执行能力；Claude Code、Kimi、Hermes、MiMo 等走不同协议，取消、续接、视觉输入和只读能力也应分别确认。E23

打开交互架构图。图中展示主要组件关系；省略的调用由下表补充，图中的“本地”不表示模型推理也在本机进行。

Python 不负责从世界知识中决定哪个来源更可信，也不替模型完成行业判断。它可以拒绝跨任务来源 ID、过期版本或超预算请求；不能仅凭对象结构合法就证明分析正确。相应地，Agent 可以提出下一轮问题，但不能靠修改自然语言计划扩大已经授权的联网预算。E02

这种划分让程序规则较小且可复现，保留模型对不同报告任务的适应性。代价是，结构检查之外仍需要产物评价和真实使用验收，特别是研究取舍、图表价值和读者是否还需要大量删改。

3. 需求、内容方法与 Word 模板

3.1 本轮约定控制交付目标

报告要求既有内容，也有方法和偏好。“说明本季度交付变化”是读者需要的答案；“优先查公告”是研究方法；“融资进度待人工填写”是明确分工。将它们分别表达，可以避免用完成一次搜索替代回答问题，也避免把用户指定的空白章节判成遗漏。

deliverable_spec 将本轮要求投射给不同角色。读者条款保留稳定身份，评价和交付规则据此关联检查结果。企业内部报告的写作指令要求先完成各章节事实和分析，再写摘要；准确写出主体、日期、单位和实际／计划阶段；将研究过程放入记录，仅在限制会改变主要判断时就地简短说明。E03

例如，“公司计划明年一季度试产，近期跟踪设备到场与客户认证”保留了阶段性质和观察节点。重复追加“计划不等于投产、投产不等于收入”，通常不再增加分析信息。这里依靠写作目标和评价要求约束表达，不采用全局删除否定词的文本替换。

企业背景知识库也是一次显式选择。当前 Store.create_run 在内部报告模式、且用户尚未选择是否维护背景时拒绝直接开工；用户可以选择不维护并继续。启用后，任务记录背景修订身份。历史背景提供研究语境，不能自动替代本期来源。E01

3.2 内容方法形成可保存的版本

当前内容方法有四个家族：general_report、business_report、meeting_minutes、stock_research。每个家族提供规划、写作和评价指令。freeze_workflow 保存具体指令、方法清单、角色适用范围和内容哈希，普通报告后续读取自己的 workflow_snapshot。E04

会议纪要要求以本次转写或笔记为材料入口；没有选定会议材料时不能用公开搜索代替。证券研究方法则约束其专业问题与分析方式。这是内容职责的区别。内置 Word 的主题和配色可以更多，但主题数不能用作专业流程数量。

3.3 模板保存组织与版式

通用模板与用户定制模板共用富文档渲染路径。用户主 DOCX 经准备后形成 prepared.docx 和模板说明，保存章节、样式及原件身份；导出时从准备后的 Word 底稿加载，替换本期字段、填入正文和资源。原模板与准备稿都参与完整性检查，底稿变化时需要新模板版本。E05

默认沿用主章节和顺序，用户明确修改时以本轮要求为准。章内小节、图表和篇幅可随内容调整。版式复用不意味着新旧报告逐页相同：文本长度、字体环境和表格高度会重新决定分页。验收应检查样式与组织是否保留、往期内容是否清除、图文是否完整，以及实际 Word／WPS 阅读是否可用。

4. 0.21.0：把研究深度保存为任务状态

4.1 三种档位及共享预算

0.21.0 的 research_tier 提供 quick、standard、deep，默认 standard。冻结研究计划时读取任务已保存的档位，保存结构、实际预算、宿主、模型及搜索提供方。后续执行依据冻结记录，而非临时读取用户刚更改的全局设置。E06

这些是代码中的起始配置，不是经过质量调优的最优值。任务若已有授权预算，冻结过程保留该预算；预算不足时默认结构会缩小。breadth 指导问题展开和任务分配，depth 限定轮次，parallel 表达并行安排；真正控制受控联网消耗的是共享预算的预留与结算。不能把三个数字相乘解释为必然发生的模型调用数。

预算分别计算搜索请求、接纳的候选地址和来源正文页。搜索结果数量、下载正文数量和模型 Token 是不同量；这一预算不能单独保证总 Token 或提供商账单上限。模型宿主自己的网络工具也不自动经过该计量入口，受控工具预算不能被宣传为所有宿主的强网络隔离。E07

4.2 轮次由模型推进，状态由程序接纳

deep 在冻结时按 depth 预建轮次：首轮 active，其余 pending；各轮预分配 breadth 个 Scout 槽位。quick 与 standard 先建立首轮，后续按需追加。预建轮次不是已完成研究，界面进度要区分 pending 与实际打开的轮次。

主 Agent 分配研究问题，研究子任务保存结果，然后关闭当前轮并登记缺口。下一轮通过 target_gap_ids 指向已有缺口；不存在的缺口、尚未结束的上一轮或超过 depth 的请求不能直接接纳。主 Agent 决定是否继续，以及缺口值得投入多少剩余预算；Python 不依据一句摘要自动生成无限递归研究树。

并发 Scout 使用 scout-1/、scout-2/ 等独立输出目录，各自写入结果，再由 join_scouts 检查目录归属、任务槽位以及来源／陈述身份后汇总。这样能减少多个任务覆盖同名文件的风险。目录分配本身不是文件系统沙箱，不能阻止拥有更广权限的宿主访问其他槽位，也不能消除共享数据库中的并发问题。E08

当前取证实现通过 rev 和事务内比较更新处理已有计划的竞争写入：读到过期修订号后重新读取并重做变更。并行维护分支采用了另一种更集中事务边界的修复，最终集成必须统一两者。本文描述的是取证副本机制，尚未宣称首次 freeze 的并发接纳与所有轮次竞争都已完成发行验收。E06

4.3 研究交接保留短摘要与回溯入口

每轮可以保存 handoff.json，内容包含 learnings、后续问题、已覆盖内容和未决问题。learnings 同时携带来源 ID 和定位字段；完全没有引用的条目标为“待证”，不能伪装成已有来源支持。check_handoff 拒绝裸 URL 充当来源、跨任务来源和缺少一半引用字段的条目。E08

构造生成输入时，运行时会寻找最近已关闭且存在交接文件的轮次，校验后加入 input.json.research_handoff；另从持久化账本读取剩余预算。格式错误被显式交给下游处理，不悄悄作为可信摘要传入。提示词要求研究子任务接收交接与预算，使用行范围或字符上限重新读取必要原文。

此处有两个明确的实现边界。第一，当前定位检查只确认字段为非空字符串，尚未解析其语法或核对原文范围；“已引用”表示有已登记来源字段，不等于定位有效或事实获证。第二，重新构造生成输入已由离线检查覆盖，但同一长会话中每轮是否确实写出、读取并利用新交接，仍需真实模型轨迹验收。文件接口存在不代表模型每轮都正确使用它。

read_source 的部分读取保留完整原件，返回实际展示行号和截取提示。它减少重复塞入全文的需要，同时保留回看原件的路径；是否降低整任务 Token 或提高分析质量，需要配对测量，本文未将其作为已证明收益。

5. 搜索提供方与材料接纳

0.21.0 新的 websearch 层对 Tavily 和 DuckDuckGo 提供共用调用入口。请求先校验任务是否允许联网、是否匹配冻结提供方及是否仍有可用轮次，再预留预算；返回后保存请求记录、原始结果、接纳情况和结算结果。记录包含本地请求 ID、提供方请求身份（可得时）、run、round、操作、参数、状态和失败类别。E09

搜索命中的标题与摘要属于候选材料。需要完整阅读的网页进入正文获取路径，保存为可引用来源。Scout 汇总检查结果是否属于该任务、声明的来源是否已登记，以及来源陈述身份是否正确。它合并结构化结果，不替主 Agent判断几个子任务是否得出了足够好的结论。

DuckDuckGo 实现使用 HTML 搜索页面，无需 Tavily API Key；网页正文通过现有直接获取路径进入来源和页预算。当前它支持通用搜索与部分相对时间筛选，不提供与 Tavily 完全等价的参数能力。绝对日期等不支持条件会被拒绝，结果缺少的发布日期不能推测补齐。HTML 页面可能变化或触发限流，因此“无需 Key”只描述认证方式，不能解释为供应商稳定性承诺。

失败记录区分认证、额度、限流、超时、TLS、网络、响应格式和预算等类别。错误不能伪装成空结果或研究已经充分；已发生的失败请求按规则保留计量。冻结提供方也不会因错误悄悄切换：若改变搜索渠道，必须明确影响执行条件和后续证据可比性。

MCP 材料入口沿用同一原则，但接纳对象不同。连接器配置描述服务，报告授权冻结允许访问的资源／工具和调用、字节预算；结果保存为来源原件封装、提取文本和 provenance，再进入报告依据。授权撤销与材料接纳检查分开处理，Reviewer消费保存后的材料，无需接收实时连接器凭据。E10

6. 写前证据对照与写后独立核查

6.1 来源陈述与报告主张不同

一条材料写“本季度发货 25 GWh”，另一条研究报告给出不同统计值，首先需要知道它们是否同主体、同时间、同口径。来源陈述保存原文说法、主体、指标、期间、口径与归属；报告主张则是作者决定写给读者的结论。未采用的来源说法不应全部被判为“正文漏写”。

reconciliation 保存写作前对照，支持九种关系：兼容、不同口径、时间先后、更正、取代、转载、不同归属的观点、矛盾和未知。关系选择与处理理由来自 Agent；代码检查成员、依据片段与关联对象归属，并要求已检查／未检查集合完整划分冻结的来源陈述。E11

例如，新公告明确更正旧金额时可以记录 correction；两个期间的数值可能是 temporal_sequence；无法解释的同口径冲突保留 contradiction。程序不根据两个数字不同就自行裁决，也不要求每组差异都写成长段免责声明。对照结果帮助作者选择准确表达，并让 Reviewer理解结论形成过程。

需要处理的分歧另有 conflicts 状态记录，可关联来源更新、企业背景候选及报告陈述。用户选择“采用新材料”并填写理由后，状态进入 addressed_pending_review，表示处理意见已保存。经核查结果接纳后，程序按具体裁决更新冲突和相关企业事实；裁决仍为 unresolved 时保持 open，其余受支持的处理可进入 resolved。因此，用户选择决定希望如何处理，独立核查确认这一处理是否有依据。对照关系不会仅因被登记就自动成为已解决冲突。E24

6.2 核查消费确定版本

草稿保存 reconciliation_id。审阅包同时记录稿件身份和哈希、正文、需求、来源身份与原件哈希、证据绑定、图表、来源更新及对照。当前 snapshot_version=6 显式包含 source_statements 和绑定 reconciliation，并将来源陈述从候选报告主张中排除。E12

独立 Reviewer 检查这份包中的实际产物和原件，不重新研究或替作者修稿。其只读权限取决于实际宿主提供的能力；不能把角色提示词当成操作系统隔离。宿主缺少所需限制，或核查未走到，就应如实记录，不能用主 Agent 自评补称独立核查。

以 OpenCode Reviewer 为例，_permission_rules 先配置全工具 deny，再为审阅包中逐一列出的文件添加 read allow，并拒绝包内符号链接。shell、写入、网络、委派和继承的 MCP 工具没有获得放行。这是由 OpenCode 执行的工具权限规则，提供了比提示词更明确的限制；它不是操作系统防火墙，不能写成模型服务进程已被“物理断网”。实际规则执行与其他宿主的能力仍需各自验证。E25

评价结束后，主 Agent 可在既定规则与预算内进行一次针对性自动修订，并复核改动。初稿先保存并可见，修订失败时不抹掉它。新版本的适用核查需要检查内容、依据和历史响应范围；旧评分不能仅因标题或 run 相同而自动适用。

6.3 普通工作稿与正式交付

普通导出服务于继续工作。正式交付还需要适用的完整独立核查、核心主张及推断前提的支持范围、重要冲突处理和确定性数值／引用检查。release.decision 输出具名 blockers 与 notices；分数高低不是唯一规则。E13

这些是当前规则中的例子，不是固定“12 项”清单。数值检查只对支持的定位和计算范围负责；无法检查的项目保留未检查状态，不把它们当成已经通过跨量纲验证。

确定性检查能指出已定位数值不匹配或引用不存在，但不能证明没有绑定的数字正确。表达偏好、研究方法未完成与事实错误也需要区别处理。当前取证基线仍存在条款 ID 软硬映射与“必答内容 unverified”处理需要收口的问题；维护分支的修复和产品规则必须在发行冻结时核对，不能在技术报告里先行假定已解决。

6.4 可单独导出的审计包

用户可以为正式交付单独制作 ZIP 审计包，逐来源选择原件、摘录或元数据范围。audit_bundle 按选择投射材料与记录，列出省略和变换，移除已知隐藏推理字段并执行记录脱敏。最终报告本身是独立交付内容：限制某份原件的打包权限，不等于从已写好的报告中自动消除所有相关信息。E26

verify_bundle 直接读取 ZIP 条目，不落地解压或执行包内脚本，也不调用模型。它检查路径、清单、哈希、版本及引用关系，并用包中冻结状态重新运行确定性交付规则。返回结果明确限定为结构与一致性校验。SHA256 可发现内容与清单不一致；若攻击者连同清单一起重写，它本身没有独立签名或可信外部锚点来证明发布者身份，也不能重新证明模型核查的事实结论。

7. 富文档、编辑与可重复的 Word 制作

7.1 保存富文档结构

只使用 Markdown 会损失表格合并、图片身份、文字颜色等信息。BriefLoop 将经过校验的 Tiptap JSON 作为正文模型，Markdown 保留为兼容投影。文档模型允许段落、标题、列表、表格、图片和引用节点，限制允许属性、颜色、合并范围和资源形式；图片引用已登记的图表身份。E14

7.2 从指定版本制作 Word

用户在网页改稿时生成新的正文版本，图表资源与引用关系需要随之保持一致。Word 制作由用户触发一个独立作业，读取已保存版本；不是实时重绘桌面文档，也不再次调用模型写一篇文章。制作过程依次读取输入、填充图文、检查 DOCX、保存并给出下载结果。E15

导出指纹包含稿件身份与内容、需求、图表字节哈希、模板修订与准备身份，以及 renderer 版本。队列执行前重新比较输入，可拒绝将变化后的材料装入旧任务。文件通过临时文件和替换操作保存，最终有自己的 SHA256；可解析的 DOCX 仅说明容器可读，真实分页和字体仍需原生 Word／WPS 检查。

还有两个容易混淆的条件。renderer 身份保证渲染实现改变后不错误复用旧缓存；导出请求的原子接纳保证并发点击不创建重复作业。本文取证基线的普通导出查询与入队尚分离，原子接纳修复在维护分支，不能把指纹存在等同于并发幂等已完成。同样，富文档到 Markdown 的显式转换保护已在维护分支推进，必须随最终合并验收。E18

7.3 接回 Word／WPS 修改

word_import.import_revision 让用户选择基准版本并导入外部修改的 DOCX。基准必须仍是当前版本；导入保留修订原件，并尝试恢复段落、标题、文字样式、表格和内嵌图片。可识别的 [1]、[2] 按基准正文的来源顺序映射为 citation 节点，因此只有来源序号仍保持原来含义时才能正确恢复，不能自动理解任意重编的参考文献。E27

已有图片通过字节哈希识别，新内嵌图片在对齐接纳后登记为图表资产，并提示核对原始数据。登记证明资源已保存，不证明新图数值正确。有标题的文档按匹配标题及顺序检查；无标题时使用文本相似度。对齐不足或含不支持的原生图表、嵌套表格等对象时保留原件并返回 needs_alignment，而不直接把错位内容送入学习。

这条入口使线下修改能够形成新的网页稿件版本，并保留其与原稿的关系。它支持一组明确的 Word 内容结构，不承诺任意批注、修订标记和复杂版式都能无损回流。

8. 反馈学习：比较产物，而非只积累指令

8.1 人类意见可立即记录，机器经验需要可追溯来源

用户显式指定的模板、章节、人工分工和写作偏好直接进入任务约定。可迁移经验则进入 WikiSkill：维护者整理反馈，提议者生成技能候选，再围绕案例生成或复用基线、产生候选稿，交由比较环节判断。Wiki帮助选择做法，不承担当期事实数据库职责。

WikiSkill 的入口规则明确允许人类建议无需模型裁判批准即可进入 Wiki，并要求保留原始措辞和来源。实现会保存人类反馈记录，再由 Wiki 视图展示；这不意味着所有意见直接成为已验证事实或已采用技能。Maintainer 提炼的 pattern 必须引用本轮允许的训练记录、人类反馈或已有 Wiki 来源 ID；白名单检查的是来源归属，不是机器自动证明经验有效。E28

8.2 人类明确要求与普通优化采用不同策略

取证副本的反馈比较使用 lightweight_pairwise：在有效成对结果中，better 数多于 worse，且没有任何 regressions，候选才获采用。一次候选被拒绝不等于永远丢弃这条反馈；是否继续受已配置学习轮次控制。

并行维护分支新增 explicit_human_requirement。只有来源记录为 human、学习意图为 explicit_requirement 且进入本次要求集合的项目适用。每对结果必须给出全部要求的 fulfilled 布尔值及具体证据；全部满足、worse 为零且无 regressions 时才采用，结果全部为 tie 也可以满足这一规则。未满足时记录 REVISION_REQUIRED 和 requirements_pending，保留要求并在剩余轮次内继续修订；轮次耗尽不会自动无限续跑。该策略尚未进入本文冻结的 0.21.0 副本，须随最终集成确认。E29

程序校验要求检查的完整性，并据给定判定选择候选；fulfilled 与 regressions 的语义判断仍需评价者依据实际产物完成。人类提出目标的权利、候选是否准确落实目标、最终经验是否有长期收益，是三件分别记录的事。

8.3 外部评分器需要本机执行授权

WikiSkill 的通用 product 工作流允许配置外部 scorer。执行前，scorer_trust 将命令、解析后的可执行程序、工作目录路径、超时、工作区身份和直接文件哈希绑定为指纹；操作员检查并通过 wikiskill scorer trust 授权后才执行。换工作区或直接文件变化可能使回执不再适用，失败评分保留实际输出，不伪装成低分。E28

这是应用层的本地执行授权，不是操作系统沙箱。它不递归计算整个工作目录和全部导入依赖的哈希；获准脚本仍以正常宿主权限运行。此机制也不等于 BriefLoop 每次反馈比较都在调用外部打分脚本。

8.4 同条件比较与跨期收益

有效比较需要固定来源、需求、内容方法、评价规则、宿主与模型等条件，只改变待验证技能。若基线来自旧写作方法而候选来自升级后的新方法，候选改善不能归因于技能。当前 0.21.0 取证基线仍存在学习 trial 重新冻结当前 workflow、旧基线复用未完整比较方法身份的风险；并行维护分支已经针对这一条件提出并实现修复，需要在最终发行树中确认。E16

另一个分支的 W5 已保存同条件基线和候选、方法哈希、比较结果与采用记录。单例中候选更好落实了用户指定的“负责人／动作／日期”结构，并保留事实与未知状态；它说明该案例的生成—比较—采用链有实际产物。它不证明多个行业持续使用的平均收益，也不证明第二期报告减少了多少人工时间。E19

后续应以连续两至三期真实报告观察重复错误、有效修订率和人工编辑时间。跨期学习是否有用，最终要落到读者少做了哪些实质工作。

9. 外部 Agent、本地部署与文件去向

9.1 通过同一工作区与外部 Agent 协作

briefloop external 提供 inspect、source、submit、query、read、revise 和 export 操作。外部 Agent 可以提交报告，按准确 job 查询，读取版本，提交带 base_version 的完整富文档修订，并下载对应工作稿。写操作要求稳定 request_id，操作及回执在同一事务中接纳；相同请求重放不会被当成新任务，参数改变也不能复用旧身份。E17

这条入口复用现有 Worker。外部 Agent 发起 submit 后，报告仍由 BriefLoop 工作区配置的实际宿主执行；外部 Agent 读取并自行修改正文，再通过 revise 保存，则属于外部 Agent 完成的内容工作。两段使用的模型、成本与权限不能合并表述。当前客户端型 MCP 与 external CLI 也不能直接宣传成 BriefLoop 已提供通用远程 MCP 服务端。

9.2 失败、取消与再次打开

持久化作业使任务状态可以在窗口关闭后被查询，但恢复需要判断执行到了哪一步。请求已经接纳、模型已经返回、草稿已经保存、Word 已经落盘是不同的恢复起点。仅在文件缺失时重新制作 Word，不需要重做研究；外部客户端丢失回执时重发同一 request_id，不应新建报告；生成失败但已有草稿时，应把草稿和失败原因一起交还用户。

桌面还有进程归属问题。当前取证基线在启动时校验服务 PID、launch_id、工作区身份和回环地址，正常停止只处理自己管理的服务。但这条启动路径没有建立主进程异常消失后的父子失联通知；正常退出可清理，不能推导出强杀后也能回收后台。维护分支已经针对 owner-pipe 和工作区恢复推进修复，最终版需要通过“强杀桌面 → 后台处置 → 同一工作区重开”的原生验证。E22

Windows 环境准备路径另有 Job Object：windows-process.cs 以挂起状态创建子进程，加入设置了 KILL_ON_JOB_CLOSE 的作业后再恢复，监督进程失去所属输入管道时终止作业内进程。这覆盖环境探测、安装等受监督命令；冻结副本的工作区报告服务仍由 service.cjs 直接启动，不能据此宣称所有报告运行及其后代均已有同样的崩溃回收能力。E30

同样，停止过程要区分保存与外部调用。已接纳的短时正文保存应完成后再退出；可取消的 MCP 请求应先撤销授权和发出取消，再等待清理。若先等所有外部请求自然返回才取消，界面会表现为停止无效。该顺序已在维护分支的可控 MCP 场景中验证，本文没有把它计作当前 0.21.0 副本的成功。这里的统一要求是：保留用户已经完成的工作，并准确说明哪些步骤需要继续，避免将不确定执行状态自动重放为新的模型任务。

9.3 部署与文件去向

Web 与 Electron 共用前端和 Python 后端。桌面壳负责原生窗口、运行环境准备、所属服务生命周期和更新入口；薄安装方案复用 Electron 内置 Node，检测兼容的本机 Python 并准备应用专属环境。安装是否无需网络、工作区切换是否保留旧后台、升级如何回退，均应按实际打包行为说明，不从“本地应用”四个字推断。

因此，本地保存不等于所有处理都不离开设备。隐私说明应告诉用户文件可能经过哪个宿主和提供方、怎样选择资料与联网范围；不承诺代替第三方的数据保留政策。部署公开入口时还需单独评估认证、来源校验与授权范围，不能直接把回环地址上的开发服务当成多人云服务。

10. 验证证据：当前可以得出什么结论

本文把代码检查、作者本次运行与他人历史验收分开记录，完整索引见 证据索引。

J2 有一项重要勘误：早期汇总把单位换算案例写成“没有生成对照”，后续读取版本轨迹发现初稿实际绑定 compatible 对照，丢失发生在修订继承。只看最新正文会把版本接线问题误判为模型未识别关系。报告保留原始失败并追加解释，不回写旧成绩。E20

后续 CodeBuddy pilot 的 C 运行约 1,803 秒，其中记录到约 1,512 秒授权等待。这个墙钟值不能用来比较模型速度。其输入包含大量缓存命中 Token，子任务分账不完整；可见主会话用量也不能当作整任务账单。A/B 没有稿件，C 与 A/B 又有多项代码差异，因此该批没有形成有效的成对语义收益结论。

本文没有新增付费模型实验，没有亲自复现这些历史原生验收，也没有把 Agent 辅助判读写成人工盲评。对于本次离线检查，测试日志、确切命令和源文件哈希已与正文一同保存，便于最终发行时重跑受影响部分。E21

11. 0.21.0 发行前的技术收口

研发版本能表达设计，发行技术报告还需要回答“用户安装的工件是否包含这些实现”。最终冻结前，以下工作应与正文证据同步更新：

1. 合并可靠性修复并冻结提交。 核对条款 ID、学习方法条件、研究计划并发、导出原子接纳、富文档转换、桌面异常退出与 MCP 取消顺序。以最终文件为准，不能累加不同分支通过数代替集成证明。
2. 完成一个真实 0.21.0 深度研究闭环。 从界面选择档位，保存任务要求，实际跨轮登记缺口、写入并消费交接、受控获取来源；保留初稿、评价、修订、绑定对照和最终 Word。失败与待证也保留，不通过手工代写成稿补足产品能力。
3. 核查研究档位与预算的用户含义。 界面、聊天、external 和恢复路径保持选择；展示实际预算及预算用尽后的成果和剩余问题。不能把 pending 槽位显示成完成数量。
4. 核对同版工件。 从同一冻结提交构建共享后端 wheel，CLI／PyPI 与 Mac／Windows 复用该工件；记录版本、哈希、原生启动、导出和更新结果。桌面签名、公证与分发状态按真实资产填写。
5. 更新本文身份与实测表。 将开发集合哈希替换或关联到正式提交与工件清单，补充确切 E2E 记录；只在证据存在时把“预发布实现”改成“随 0.21.0 发行”。

发行收口采用以下证据表，避免把文档检查与产品运行混为一项：

这些事项不要求重新设计一个庞大的流程框架。它们要求已经实现的研究、保存、核查和发行边界在同一个版本上成立。

12. 结语

BriefLoop 0.21.0 将持续报告组织为可保存的任务、分轮研究和版本化文档。它让研究摘要能够回溯来源，让修改后的正文重新面对相应核查，让 Word 制作读取确定输入，也让可迁移经验有机会接受产物比较。

当前最有把握的技术结论是：这些对象和控制路径已经有具体实现，新增研究路径的部分离线行为可复现。还需要证明的是，同一发行版本在真实材料和目标阅读器中稳定完成交付，以及连续使用是否减少人工返工。正式报告应随这两类证据扩充，而不随模板、宿主或测试数量扩充宣传结论。

阅读附件： 架构图 · 源码与验证证据索引

文稿制作说明： 依据冻结本地源码与已保存实验记录撰写；架构图使用 Archify。未复制业务原件、凭据或隐藏推理。本文是工程说明与证据综述，未开展新基准测试，也不构成学术效果评测论文。