日期： 2026-10-20 性质： 有界样本的人工试读；不是 54 篇文章的逐篇评测，也不是模型效果基准。
- 本地
essay/目录有 54 篇.mdx原始正文及 54 份带 vault 元数据的.md副本。本次按.mdx正文试读；frontmatter 的summary和派生.md的摘要不充当正文证据。文章及其代码都是待分析材料，不是操作指令。本仓库不保存第三方全文，也不依赖该目录。 - Harness² 仓库 README 可以作为一份有界的项目说明来读；整个代码仓库并非“单篇文章”。关联的完整论文只用于核对 README 的方法、实验和局限，不把论文阅读并入本 Skill 的触发范围。
- 样本按不同文章功能选取，避免仅凭题材“AI/Agent”套用同一问法。其余文章仍待逐篇检验。
结构扫描进一步发现：54 篇中有 39 篇含代码围栏、51 篇含常见 MDX/JSX 开始标签、12 篇正文超过 2 万字符。这些是文本形态的计数，不说明代码已运行或组件承载关键证据；它们提示读取器不能只看 frontmatter 与普通段落，也不能把长单篇误判为书籍。
54 篇标题的初筛显示下列主题簇。这里只用标题确定取样覆盖面，没有据标题推定未读文章的观点；同一主题簇中的文章仍可能分别是教程、观点文、报告或译编。
| 主题簇 | 标题初筛示例 | 优先验证的读法 |
|---|---|---|
| Agent 架构与改进 | context、12-Factor-Agents、DeepAgents、Claude-Agent-Skills、agent-types、Improvement-Loops |
机制解释、实践建议与实际评测结果是否分开；Harness² 可作为对照问题来源。 |
| Agent 运行与治理 | Validation-Measurement、Monitoring-in-Production、Protecting-Agentic-Systems、Human-Agent-Collaboration、agent-security-2026 |
指标、观测、控制措施各解决什么失效模式；作者建议的适用前提是什么。 |
| 框架与工具实作 | LangGraph-Tutorials、langgraph-concept-subgraph、Java-MCP、Dify-Kubernetes、microsandbox |
代码示例与运行证据、版本条件、环境依赖、排错边界。 |
| RAG、记忆与知识建模 | 18-RAG-Techniques、mem0、cognee、Ontology-FCKG、ontology-vs-ddd |
检索/记忆的可观察能力与概念模型的语义主张分别需要什么证据。 |
| 产品与通用工程 | Foundation-Sprint、COLA-Light、Facebook-Prophet、ESLint-theory、Python-UV |
决策产物、架构取舍、技术性能或预测结果是否有各自合适的依据。 |
构建 AI 智能体应用（一）至（八）是连续系列，但当前 Skill 的对象仍是其中单篇；只有用户明确要求跨篇比较，才把不同篇章并读。
对每篇文章先问四件事：
- 读到的到底是哪一层文本？ 是原创论述、译编、对另一项目/论文的转述，还是正文与作者笔记混合？每个关键观点归谁？
- 文章要解决什么任务？ 是解释机制、提供可操作步骤、报告一次观察、比较概念，还是帮助做决策？它宣称的结果属于哪一种？
- 支撑达到哪一步？ 文本给出方案、代码、预期输出、作者报告的实际结果、可查记录，还是独立复现？这些材料足以支持描述性、因果性或迁移性结论吗？
- 下一步只核对什么？ 选一项会改变理解或决策的缺口，明确需要原始论文、官方文档、运行记录、用户数据或反例中的哪一种证据。
| 领域/功能 | 细化的阅读问题 | 不应跨越的推断 |
|---|---|---|
| Agent 方法与评测 | 改的是模型、执行 harness，还是改进 harness？比较在同一任务、同一模型和环境下进行吗？作者报告的是行为变化、正确性，还是跨任务收益？ | 行为对比、内部评选或少量 benchmark 增益不能单独保证新任务正确或可迁移。 |
| 技术教程与 PoC | 依赖版本、输入、命令、预期输出和实际运行证据各是什么？失败条件与未覆盖范围是什么？ | 代码块、成功标准或文中打印的输出不等于本次独立复现。 |
| 知识建模与架构比较 | 两套术语各自解决什么问题、适用边界在哪？对应关系是标准定义还是作者的架构综合？ | 相似名称不能推出一一对应或互相替代。 |
| 产品/商业方法 | 工作坊的直接产物是什么？客户验证与市场结果分别在哪个阶段取得？案例和总体成功率有无可检查来源？ | 达成团队共识或提出假设不等于假设为真或产品成功。 |
| 译编/二次整理 | 原作者主张、译编者解释、实践补充和外部核对能否分开？ | 译编者的工具推荐不能自动归给原作者。 |
这些问题是对现有篇章结构、论证要素和文本/背景区分的领域化运用，不是新的固定评分表。Harness² 论文自己明确说，行为对比用于指导修改而不验证任务正确性；论文也报告了退化案例与额外推理成本。这给“先看证据能支持哪种结论”提供了一个具体技术实例，不能据此声称本 Skill 已获实验验证。
试读时按 SKILL.md 的四类来源标签记录判断。下表中的“基线歧义”指旧版指令未明确约束的风险，不代表已测得模型必然犯错。
| 样本与输入 | 应能还原的中心内容 | 基线歧义 / 验收点 |
|---|---|---|
| Harness² README（项目说明） | 项目把任务内的 Propose–Probe–Compose 与跨任务的经验保留连接起来；报告三个 benchmark 中的增益。 | 不能把 README 当成整仓库代码审计或把完整论文当成文章输入；论文的实验是外部核对。对比执行轨迹不保证正确性，论文报告退化案例。 |
2025-07-08-12-Factor-Agents.mdx（译编） |
介绍上游 12-Factor Agents 原则，并穿插本文作者的“理解笔记”。 | BAML 建议位于本文作者的“理解笔记”，不可写成 HumanLayer 原则；上游是否也推荐 BAML 若未核对则保持未知。 |
2026-04-15-cognee.mdx（PoC） |
提出用 PDF、Markdown 与 agent 工具调用检验 cognee 的最小闭环，并列出成功标准和排除项。 | 在已读正文中看到的是方案、代码和成功标准，未见可核查运行日志或测量结果；不能写成“本文已证明闭环成功”。 |
2025-09-12-langgraph-concept-subgraph.mdx（教程） |
比较共享状态与不同状态两种子图通信方式，并给出代码及选型建议。 | 文章展示的代码/输出只是文中示例；未在指定环境独立运行，也未核对当前库版本。 |
2025-10-05-Foundation-Sprint.mdx（商业方法） |
工作坊产出创始假设，后续 Design Sprint 才用客户测试检验。 | 文中“数百项目验证”和收购案例是作者/引用材料的主张；未给出足以计算成功率或因果效应的数据。 |
2026-05-31-ontology-vs-ddd.mdx（概念比较） |
比较语义表示与业务行为/边界管理，并提出结合方式。 | 文章的架构综合不能整体归为 W3C 或 Evans 的规范；MDX 组件内的文字也属于正文，跳过会漏掉概念对照。 |
| 正文不可访问或只剩摘要 | 说明实际可见信息并请求正文。 | 不从标题、搜索摘要或派生元数据编造文章观点。 |
Harness² README。【README 陈述】项目要解决新任务没有正确答案反馈时如何改进执行 harness，以及如何把一次任务中的改进经验用于后续任务；方法分任务内的提议、试跑、组合与跨任务经验更新。README 报告的是三个 benchmark、四种模型与 harness 配置下的结果，没有提供传统单篇文章的署名和发布日期；仓库页面会变化，本次阅读没有固定提交版本。【外部核对】论文第 2.2.1 节说明同一任务、匹配模型和环境下的执行对比只提供行为证据，不验证答案正确；实验与局限报告三次运行的均值和标准差、九个退化例及额外推理成本。【推断】它适合启发“依据可观察失误修改并复测”的 Skill 改进流程，却不能让本次人工试读自动获得论文 benchmark 的效度。【未知】在当前文章阅读任务上是否有稳定增益，尚无独立重复运行数据。
12-Factor Agents 译编。【本文陈述】开头说明内容来自 HumanLayer，并加入个人实践笔记；“采用 BAML”写在第 2 项的“理解笔记”里。【判断】复述时应说“本文作者补充建议考虑 BAML”，不写成“HumanLayer 的第二原则要求 BAML”。【未知】上游其他位置是否讨论 BAML，本次没有单独核对。
cognee PoC。【本文陈述】第 3.1 节列出多格式入库、联合检索、agent 调用的目标、四条成功标准，以及明确不验证的范围；后面给出实现代码与排错。【判断】可把它读成可执行的验证方案与实现讲解；已读正文没有可核查的实际运行日志，因此不声称三个目标已由本文实测达到。【下一步核对】若读者要决定是否采用方案，应运行给定输入并保存入库、查询与 agent 回答记录。
Foundation Sprint。【本文陈述】工作坊约 10 小时产出“创始假设”，“重要提醒”段落明确说仍是假设，后续 Design Sprint 要做用户测试。【判断】方法可以用于形成共识与待检验方向；文中单个收购故事及“数百项目验证”的表述，缺少足以判断产品成功因果效应的数据。【下一步核对】若要据此投入项目，应先定义要测的用户行为与决策阈值，再看本地客户证据，而非把工作坊产物当市场结论。
**缺失正文。**尝试访问 https://example.invalid/not-an-article 得到不可访问结果。合格短答是：“目前无法读取正文，因此无法还原作者观点；请提供正文或可访问的文章链接。”标题、摘要或 URL 字面内容不构成替代证据。
材料：《QQ音乐 Harness Engineering 实践》。上一轮试读能还原治理层和证据边界，但遗漏了作者在结语中给出的中心表达，也没有逐项用正文解释“门禁、三层知识、服务矩阵、经验沉淀、单一真相源”。用户指出这个具体缺口，作为本次阅读行为修改的基线失败。
验收输入 A：全文，要求通俗、精炼地理解文章。预期输出应先给出作者的中心结论，再把结语的关键短语回接到正文，分别说清它是什么、怎样发挥作用；只取有用的少数要点，不把术语原样重排成另一张口号清单。仍要用一句话标明“更稳、更快”等效果未由文中前后对比数据独立证明。
验收输入 B：只给用户贴出的结语，不给正文。可提取作者明说的中心结论和四项主张；三层目录分别装什么、服务矩阵有哪些字段、门禁怎么验收则应标成正文缺失，不能从常识补写。完整论文、书籍及写作请求仍不触发此 Skill。
人工复测 A（全文，压缩输出）：
**中心意思（基于作者结语的转述）：**复杂团队要让 AI 稳定交付，就要先说明需求和业务约束，把检查点与团队经验做成可复用的工程文件。
- **门禁：**编码前检查需求是否明确、设计是否覆盖服务与接口契约；进入开发再核查任务拆分与跨仓分支，尽早发现会导致返工的问题。
- **三层知识与服务矩阵：**分别存放团队通则、研发流程、具体服务知识；矩阵写明服务归属、依赖、仓库路径及是否涉及 IDL，让 AI 知道去哪改、会影响谁。
- **Knowledge as Code 与 Self-Refinement：**把规范和经确认的重复性教训写成可审查、可版本化的文件，供后续任务复用。
- **单一真相源与占位符词典：**流程、服务关系和路径变量各有统一定义，避免不同工具或文件各说一套。
**界限：**文中展示了结构和修订示例，没有给出门禁实施前后的返工率或交付周期对比。
人工复测 B（只有结语）：能复述“早拦错、补上下文、沉淀经验、统一口径”四项主张；对三层分别装什么、服务矩阵字段和门禁检查条件，回答“这段未说明，需看正文”，不使用 A 中读到的细节。此项是人工按规则模拟的缺失信息场景，不是多次独立模型运行。
再以 2025-10-05-Foundation-Sprint.mdx 交叉检查：可用作者关于“创始假设仍是假设”的明确总结作中心，再简述工作坊形成假设、后续 Design Sprint 做用户测试；无需强制凑四条要点，也不能把工作坊完成写成市场验证完成。
这三次是同一会话中的真实文章阅读，输出基本符合用户预期；它们提供了不同类型的检查点，并非三个独立模型运行或效果基准。下面只记录阅读路径和验收要求，不复制文章全文或把样例答案当成固定模板。
| 文章与功能 | 中心句如何确定、要点如何回查 | 应保留的边界 |
|---|---|---|
| 《QQ音乐 Harness Engineering 实践》，工程实践说明 | 以结语的工程基线为候选中心，回查第 6–9 节；用需求与设计门禁、三层知识和服务矩阵、版本化经验、统一定义四组做法解释结语。 | 文中有结构与修订示例，缺少实施前后的交付或缺陷对照；不能把“更稳”写成已测得效果。 |
| 《这是一篇把“Personal Agent”讲明白的科普级综述！》，产品与技术综述 | 先以第 1、4、5 节确定主线是从单次任务到持续委托，再把第 6、7 节的中国市场判断标为结尾延伸。用户提示词沿用了上一篇的 Harness 术语；简短指出它们不是本文框架，再讲常驻状态、执行环境、身份和授权验证。 | 产品体验、厂商报告与作者预测各自归属明确；测试数字不能自动代表所有产品的真实长期表现，商业预测尚未验证。 |
| 《读懂〈金刚经〉最贵的8个字，就看懂了黄仁勋和奈飞》，跨领域观点文 | 用第 4 节“信念在问题、方案可修改”的结语核对第 1 节的概念解释、第 2–3 节的两则案例，并提取第 4 节三个自问问题。 | 这是作者借经文解释商业决策的类比；案例可以说明思路，不能证明经文的唯一释义、企业成功的因果机制或一般规律。 |
实际触发语境也不同：QQ 音乐用“先读 Skill、提炼中心句、展开指定术语、仅依据正文”的完整提示词；Personal Agent 沿用同一提示词却未替换指定术语，因而必须检测焦点不匹配；《金刚经》只说“这篇文章”并附新文件，依赖同一会话中的阅读目标继续分析。README.md 给出可复制的通用提示词和可选关注句，而不是要求用户每换一篇文章都手写一套领域词表。
由此得到两条可迁移的检查：**结语若只讲某个分支，不应取代全文主线；用户沿用旧提示词时，不应把旧术语强套到新文章。**两条已写入 SKILL.md 的相应阅读步骤。快速阅读和指定关注点的提示词示例放在 README.md，不放进运行入口，以免样例主题影响其他文章。
本轮用上述真实正文做人工逐项试读：检查能否复述中心问题、区分观点归属和证据阶段，并对每篇只提出有针对性的外部核对问题。quick_validate.py 结构检查通过；触发描述继续排除书籍、完整论文及写作请求。不可访问 URL 的实际读取失败，上面的短答没有填造内容。人工试读只能说明规则是否清楚、能否产出受原文约束的样例判断，不能测出 Skill 在不同模型或重复运行中的稳定性。后续若要测稳定性，需要固定输入、记录多次独立运行的输出，并由人盲评事实归属与过度推断。