Add source links to supplemented lecture content

All factual claims verified against original articles:
- OpenAI: Harness engineering (Feb 2026) — all 8 claims confirmed
- Anthropic: Effective harnesses (Nov 2025) — all claims confirmed
- Anthropic: Harness design (Mar 2026) — all 7 claims confirmed

Add > source citation links to L01, L05, L09, L10, L11, L12.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: sanbuphy

docs/zh/lectures/lecture-01-why-capable-agents-still-fail/index.md

@@ -73,6 +73,8 @@ OpenAI 在 2025 年做了一个激进的实验：用 Codex 从一个空的 git 
 
 这个实验直接证明了本讲的核心论点：**同一个模型，在空白环境里和在有完整 harness 的环境里，产出有本质差异。** 模型没变，变的是环境。
 
+> 来源：[OpenAI: Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)
+
 ### 一个更小的对照实验
 
 一个团队用 Claude Sonnet 给一个中等规模的 Python Web 应用（FastAPI + PostgreSQL + Redis，约 15,000 行代码）添加新的 API 端点。

docs/zh/lectures/lecture-05-why-long-running-tasks-lose-continuity/index.md

@@ -111,6 +111,8 @@ Anthropic 在 2026 年 3 月发布的研究进一步揭示了上下文焦虑的
 
 Anthropic 的实际数据：对于 Sonnet 4.5，上下文焦虑足够严重，以至于压缩单独不够用，上下文重置成为 harness 设计的关键组件。但对于 Opus 4.5，这种行为大幅减弱，可以不依赖重置而靠压缩管理上下文。这意味着：**harness 设计需要对目标模型有具体的理解，而不是套用通用模板。**
 
+> 来源：[Anthropic: Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+
 ## 实际案例
 
 一个 agent 被要求实现一个带用户认证的博客系统，12 个功能点，预计需要 5 个会话。

docs/zh/lectures/lecture-09-why-agents-declare-victory-too-early/index.md

@@ -55,6 +55,8 @@ Anthropic 在 2026 年的研究中发现了一个更深层的失败模式：**
 
 这是同一个模型（Opus 4.5），同一段提示词（"做一个 2D 复古游戏编辑器"）。区别只在 harness——从"裸奔"到"planner 扩展需求 → generator 逐功能实现 → evaluator 用 Playwright 实际点击测试"。
 
+> 来源：[Anthropic: Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+
 ## 怎么做才对
 
 ### 1. 外部化终止判定

docs/zh/lectures/lecture-10-why-end-to-end-testing-changes-results/index.md

@@ -64,6 +64,8 @@ OpenAI 采用了"分层领域架构"——每个业务领域（如"用户设置"
 
 关键原则：**执行不变量，不微管实现。** 比如要求"数据在边界解析"，但不规定用哪个库（模型自己倾向 Zod，但 harness 没指定）。错误消息要包含修复指导——不只是说"违规了"，而是告诉 agent 具体怎么改。这种面向 agent 的 lint 比"人类看的"文档有效得多。
 
+> 来源：[OpenAI: Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)
+
 ### 1. harness 必须包含端到端层
 
 在你的验证流程里明确：对于涉及跨组件修改的任务，端到端测试通过是完成的前置条件。在 CLAUDE.md 里写：

docs/zh/lectures/lecture-11-why-observability-belongs-inside-the-harness/index.md

@@ -130,6 +130,8 @@ QA 第 1 轮反馈的示例——"这是一个视觉上令人印象深刻的应
 
 Evaluator 不是一开始就这么强。早期版本会识别出合理的问题，然后说服自己这些问题不严重，最终批准工作。调校方式是：读 evaluator 的日志，找到它的判断和人类判断分叉的地方，更新 QA 的 prompt 解决那些问题。经过几轮这种开发循环，evaluator 的评分才变得合理。
 
+> 来源：[Anthropic: Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+
 ### 更小规模的案例
 
 一个使用计划者-生成者-评估者工作流的 harness，执行"添加暗色模式支持"任务：

docs/zh/lectures/lecture-12-why-every-session-must-leave-a-clean-state/index.md

@@ -33,7 +33,7 @@ OpenAI 团队最初花每周五（20% 的工作时间）手动清理 "AI slop"
 
 这个机制就像垃圾回收——技术债是高息贷款，持续小额还清几乎总是比攒到一次性爆发好得多。
 
-真实数据很说明问题。一个使用 agent 持续开发 12 周的项目，没有清洁策略的情况下：
+> 来源：[OpenAI: Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)一个使用 agent 持续开发 12 周的项目，没有清洁策略的情况下：
 
 - 第 1 周：构建通过率 100%，测试通过率 100%，新会话启动 5 分钟
 - 第 4 周：构建 95%，测试 92%，启动 15 分钟