长 Prompt 直出
相同来源包与报告要求下，一次性生成的周报及其原始运行记录。
运行包准备中策略更新日期写为 2026-06-31，与事实不一致。
切换下面三个典型合成场景，看同一份材料两种交付方式的差别。
…
读起来通顺、自信——错误就藏在里面，没有任何提示。
…合成案例，用于解释工作流，不代表自动事实核查基准。
Prompt 和 Skill 告诉 Agent「应该怎么做」；BriefLoop 记录它「实际做了什么」，并决定哪一版有资格交付。
最大的区别不是多一个审稿 Agent，而是写稿的 Agent 没有权把自己的稿子直接宣布为「可以交付」。
写得好，但规则只活在这一次对话里。
能调工具、跑多步，但写稿和裁判还是同一个。
把关键事实、检查和批准放到 Agent 之外。
| ChatGPT + 长 Prompt | Agent Runtime + Skill.md | BriefLoop | |
|---|---|---|---|
| 主要作用 | 生成内容 | 自动执行任务 | 管理报告从草稿到交付 |
| 规则如何生效 | Agent 按 Prompt 理解遵守 | Agent 按 Skill 和 Runtime 执行 | 关键边界由外部状态、程序检查和权限控制 |
| 谁判断任务完成 | 通常是模型或用户 | 通常是 Agent 或 Runtime 流程 | 写稿 Agent 无权单独宣布可交付 |
| 关键数字如何保存 | 存在于材料和对话中 | 可能保存在中间文件中 | 关键事实单独登记，改动必须留痕 |
| 发现错误后 | 继续对话、重新生成 | Agent 重试或重跑步骤 | 问题入账，阻断交付，修复后重新检查 |
| 哪一版算最终稿 | 最后一次回答或生成的文件 | Agent 标记完成的结果 | 通过检查并获批准的版本 |
| 运行中断后 | 依赖聊天记录和上下文 | 取决于 Runtime 是否存状态 | 根据工件和运行记录恢复 |
| 最适合 | 一次性、低风险写作 | 多步骤自动化 | 重复、高风险、多人复核的正式报告 |
ChatGPT 负责想和写，Skill 负责教它怎么做，Runtime 负责让它跑起来，BriefLoop 负责记账、拦截和放行。
这些能力 Agent Runtime 自己也能实现——但都做完，其实就是在重建 BriefLoop。区别不是别人做不到，而是你不必每个团队再用 Prompt 和脚本各拼一遍。
Skill 是「请你这样做」，BriefLoop 是「没做到这一步，就过不去」。
本地文件、报告、表格，或已登记的网页材料。
目前通过 Codex 起草。
看数字有没有出处、材料是否过期、是否突然多出新的重要结论。
未处理的问题不会被当成最终稿。放行的永远是人，且留有记录。
v0.15.3 的新运行只走 Experimental Codex SQLite 路径。SQLite ControlStore（briefloop.db）及其收据、账本关系是唯一运行权威；Agent 只能写 invocation scratch 提案，确定性服务才可接受并生效。旧 JSON 控制面已删除，不能导入或双写。legacy JSON 控制文件与报告、status、Quality Panel、Markdown/JSON/JSONL/HTML 导出是非权威投影。strict action、envelope 与 human-request JSON 只是写边界载体，必须重新对照 ControlStore 校验，自身不构成权威。完整机制见 运作原理。
先看它有什么用，文件名点开再看。
通过全部检查、经人工批准后才成为最终稿的报告。
每个关键数字对应哪份材料、第几页，一眼可查。
哪些地方还没出处、还在冲突、还需人来判断，都列在这里。
放行是谁、什么时间、基于哪一版，全程留痕。
v0.15.3 可导出一份自包含的只读 HTML：Brief、Quality、Market Data、LAJ 建议、改进状态。它只是 Store/LAJ 的展示投影，不是运行权威、质量评分或交付裁决；LAJ 为 Experimental，效用 NOT MEASURED。
合成数据 · 只读展示。第三页会如实显示 Improvement Ledger unavailable；页面没有处置、写入或“接受建议后改善下次运行”的能力。
相同时间窗、来源包、模型与交付要求。真实运行完成并核验后，这里会公开三份成品、问题记录与运行包；不把“看起来最好”的一次挑出来当结论。
相同来源包与报告要求下，一次性生成的周报及其原始运行记录。
运行包准备中相同来源包与报告要求下，Agent 使用公开 Skill 完成的周报与运行记录。
运行包准备中相同来源包与报告要求下，附事实登记、问题记录、修复与人工放行状态。
运行包准备中三类最常见的定期交付，各自最容易出的问题。
要交：每周的行业动向和竞品跟踪。
常拦住：多轮改稿后混入的未证实数据和观点；核心数字先冻结再润色。
要交：给管理层的月度经营与决策简报。
常拦住：把「预计」写成「已完成」、过于绝对且缺乏归因的结论。
要交：对 AI 草稿做出处与合规复核的结论。
常拦住：过期或无依据的陈述被标记并阻断，复核只看例外。
BriefLoop 不会自动证明某句话绝对正确，也不会替代法律、合规或管理层判断。它做的是把出处、冲突、过期材料和未解决问题摆到你面前，并防止这些问题被悄悄当成最终稿。
举个例子：它不会证明「需求一定没有回暖」；它只是指出，当前提供的材料不足以支持这个结论。
以下页面展示 v0.15.3 的产品边界；均为合成数据，只用于说明界面，不构成能力测量结果。
真实 briefloop init --web 是 Experimental 的本地一次性向导；本站页面只是只读界面预览，不创建工作区、不提交事务。
终稿后的 advisory 第二意见，不影响 Gate、交付、批准、下一动作或事实支持结论；效用 NOT MEASURED。
打开设计预览 →HTML 的 Improvement 页只读显示不可用。没有自动学习。v0.15.3 的人工观察与批准指导走 Store Receipt，下一轮只有显式 --include-approved-guidance 才会带入。
不用装任何东西也能先看它抓错；想本地跑起来，下面二选一。
在 Codex 中说：
「我想用 briefloop.ai 做周报」
执行任何动作前，请先读取：
https://briefloop.ai/.well-known/briefloop-agent.json
然后读取 manifest 指定的 canonical Skill。不要从本首页自行推断仓库、安装方式、runtime 或能力边界。
它应先读取安装说明、向你确认目录和权限，再按你的系统路径逐步验证安装；不要把对话里的“完成”当成安装成功。
git clone https://github.com/Stahl-G/briefloop.git
cd briefloop && bash scripts/setup.sh
需要 Python 3.12。装好后 source .venv/bin/activate，可先跑 bash scripts/demo.sh。建工作区用 briefloop new industry-weekly ./my-weekly，或先 briefloop onboard 再 init --from-onboarding。Windows 请使用 PowerShell 安装路径，不要把这两行 Bash 改写到 Git Bash。pipx install briefloop 目前不是启动路径。
想先在线体验？看三个抓错演示。完整安装与治理细节见 Agent 安装说明 与 运作原理。当前能力边界以仓库里的 architecture-status 为准；页面上的 架构参考 v0.6.1 是 v0.12.1 代码快照，不是 v0.15.3 能力声明。