markupbase

一句话定位

不是给 agent 装更多日志，而是给"该被评审的工作"立一份独立工件——人类可读、带版本、绑证据， 让人在 agent 干完活之后还能看懂、质疑、叫停。

做这个东西的人

MarkupBase 公司（markupbase.com）2026 年 8 月发布的白皮书《Making Autonomous Work Reviewable》。 它同时是一家做"人 + agent 共同评审 Markdown/HTML"的产品公司：发布工件、行内评论、不可变版本、 通过 MCP（mcp.markupbase.com）给 agent 派评审任务。

判断：一个卖"评审"产品的公司，先写一份"评审为什么值得独立存在"的方法论，再让产品承接结论。 白皮书是零成本动作，真正要看的是框架有没有被自家产品之外的人采用。

它到底能做哪几件事

白皮书部分：

• 定义"评审工件" → 一份回答九个问题的工作陈述：请求了什么、范围是什么、改了什么、为何选此方案、什么支撑结论、什么可能出错、可否回滚、需要何种人类判断、批准的是哪项工作
• 否定三种旧评审载体 → 对话记录（只记说了什么）、活动日志（只答窄问题）、审批弹窗（只显示命令、看不出业务影响、会退化成条件反射）
• 给出四种评审模式 → 行动前提案、行动后记录、按例外审查、定期审查，可并存
• 四层行动分级 → 0 观察 / 1 可逆 / 2 重要 / 3 关键，从"定期抽样"到"双人控制 + 完整证据 + 留存决策记录"
• 八项可信要求 → 批准绑定精确动作、版本不可变、主张连证据、身份权限清晰、最小权限、不确定性可见、敏感材料保护、源码与渲染视图并存

产品部分：发布 Markdown/HTML 工件 → 人/agent 在同一不可变版本上留行内评论 → 评审请求与状态 → 版本历史。安全上做隔离预览与身份分离。

它明确不做：不替人做最终决定，不做执行层工具——这是"为评审而设计，不是为执行而设计"的刻意收敛。

它在替代什么旧行为

以前人审 agent 的活，靠三样东西：翻聊天记录（记录说了什么，不记录发生了什么）、 查活动日志（能回答哪个调用、何时、有没有报错，答不了为什么）、点审批弹窗 （显示一条命令，看不出业务影响，点多了就退化成条件反射）。

这三样全都在 agent 的流水账里打转。白皮书的动作是把评审对象从流水账里抽出来， 立成一份独立的、带版本、可锚定到具体句子和表格的工件——评审看工件，不看对话。

这个替代关系要成立，工件必须比流水账便宜、比流水账更经得起"稍后再看"。

商业模式

未披露。 白皮书无定价；markupbase.com 产品页未显示定价与用户数。

判断：白皮书公司的通病是"思想领导力先行"，先立品类再谈收费。这个框架能不能变成钱， 取决于"评审工件"会不会被更大的 agent 平台当成标准抄走——被抄走是流量，被抄走还收不到钱才是风险。

硬数字

• 白皮书引用的公开教训：Knight Capital 2012 年 45 分钟损失 4.6 亿美元；Moffatt v Air Canada（2024）聊天机器人误导被判担责；Mata v Avianca（2023）律师提交 AI 编造案例；Replit（2025）agent 删库
• 4 个匿名合成案例 + 4 个公共先例；评审工件模板 9 问；行动分级 4 层
• HN：5 分、1 评论
• 产品用户数、定价：未披露

四维评估

判断

"评审工件"是可迁移的好框架，但它是白皮书，不是产品。 给高风险 agent 输出立独立工件、审批绑定精确版本、按行动级别配不同评审强度——这三条 对任何"要让 agent 干真活"的产品都适用。它最值钱的一句话： 有用的追问不是人是否留在每个环里，而是人是否还能看见、质疑、支配重要的工作。

它的软肋比 numbat 更靠前：numbat 至少有端上代码，这里只有一份框架。 白皮书谁都能写，框架被采用才有护城河。目前 5 分的 HN 热度，说明市场还没接住它。

判断的顺序：先看有没有平台级采用，再看产品本身卖不卖得动。两者都不是，就只是又一份好文档。

下一步看什么

① "评审工件"有没有被主流 agent 平台或公司引为标准实践 ② markupbase 产品有没有公开用户与定价 ③ 九问模板有没有衍生出第三方模板或工具（被复制的指标）

可借鉴的做法

产品逻辑：把"评审"从对话记录里独立出来，做成版本化、可行内注释、绑证据的工件； 给操作分级（0 观察 / 1 可逆 / 2 重要 / 3 关键）并配不同评审强度；审批必须绑定到精确动作与版本。 做 AI 产品时，"评审层"本身可以是独立产品。

定价结构：无。未披露。

结论

值得关注。 框架有增量价值，产品未验证。三个月后拿上面三条回头验证。