用 Obsidian 替代 idea 作为 AI 时代的"认知承载层"——把 Andrej Karpathy 的「Obsidian is the IDE, LLM is the programmer, wiki is the codebase」落到实处：Claudian 插件 + 根 CLAUDE.md schema + Ingest / Query / Lint 三个操作，再加上一次两周跨度重构的实战复盘和两条可直接跑的 Vault Lint prompt。

AI in Harness 系列收官篇——把前三篇（Loop / Tools / Skill / Memory、Error Recovery / Task System / Background Task、Multi-Agent 协同）串起来给出 Harness 的完整定义：让 LLM 在"受控循环"中工作的一整套基础设施。附模块总览图、每个模块的职责边界、模块之间的调用关系，回答"什么是 Agent Harness、和 Agent Framework 有何区别"。

AI in Harness 系列第三篇——为什么 Subagent + Background Task 之后还需要多 Agent 协同：Agent 之间的通信 Protocols、Autonomous Agents（自主 Agent）如何让主控在长任务中"托管"给下游、以及用 git Worktree 做并发文件写入隔离避免相互覆盖，让多个 Agent 真正能同时改代码。

AI in Harness 系列第二篇——LLM 长周期任务如何跑得稳、跑得远：错误恢复（Error Recovery）如何区分可重试/致命错误并降级、Task System 如何做任务规划与依赖调度、Background Task 如何在主循环之外并发执行长耗时子任务并回写结果。以 Java Harness 框架的实现代码作为落地参考。

AI in Harness 系列第一篇——从 Prompt Engineering 到 Loop Engineering 再到 Agent Harness 的演进：为什么"能跑"的 Loop 还不够，Harness 需要在此之上补齐 Tools、Skill、Memory 三块能力，以及 CLAUDE.md / 系统提示词 / 用户消息 / 工具结果的上下文分层加载策略。以 Java 视角剖析 Claude Code 实现，配可运行的开源 Java Harness 框架。

负载均衡

前端

使用 DNS 进行负载均衡。在 DNS 回复中提供多个 A 记录或者 AAAA 记录。
虽然 DNS 看起来简单，但是存在不少问题。

1. DNS 对客户端行为的约束很弱：记录是随机选择的。
2. 客户端无法识别“最近”的地址
3. 权威服务器不能主动清楚某个解析器的缓存，DNS 记录需要保持一个相对低的失效值（TTL）。

测试可靠性

预测信息准确的前提：

1. 系统完全没有改变
2. 充分描述整个系统的改变

测试是一个用来证明变更前系统的某些领域相等的手段。

事后总结：从失败中学习

哲学

保证事故能够被记录下来，理清所有根源问题。确保实施有效的措施是的未来重现的几率和影响得以降低，甚至避免。

书写事后总结不是一种惩罚，而是整个公司的一次学习机会。

需要书写的标准：

• 用户可见的宕机或者服务质量下降到一定标准
• 任何形式的数据丢失
• on-call 工程师需要人工介入
• 问题解决耗时超过一定限制
• 监控问题

应急事件响应

测试导致的事故

SRE 故意破坏系统，利用这些测试发现系统的薄弱地方。

在某次测试中发现了额外的系统依赖。

响应

• 终止测试
• 用以前 测试过的方法 回滚了数据
• 找到开发者修复了相关问题
• 制定了周期性测试机制来保证问题不重现

事后总结

好的方面：
事先沟通，有足够信息推测是测试造成的问题。
快速恢复了系统。
遗留一个代办，彻底修复问题。制定了周期性的测试流程。

有效的故障排查手段

理论：

反复采用假设排除手段的过程：
不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除

常见的陷阱

• 关注的错误的系统现象，或者错误地理解了系统现象的含义。
• 不能正确的修改系统的配置信息，输入信息或者系统运行环境。
• 将问题过早的归结为极为不可能的因素，或者之前曾经发生过的问题
• 试图解决与当前问题相关的一些问题，却没有认识到只是巧合。