AI in Harness（三）
多Agent 协同 - 需要一个团队
前面我们实现了 Subagent、Background Task，为什么还需要多 Agent 协同呢？
一句话区分
- Background Task = “把这个工具调用派到后台跑,我等结果通知“
- Subagent = “派一个新 agent 干一件具体事,跑完销毁,我等摘要“
- Teammate = “派一个长期协作的队友,我们持续异步通信”
对比表
| 维度 | Background Task | Subagent | Teammate |
|---|---|---|---|
| 被派的是什么 | 一个工具调用(bash) | 一个全新 agent(独立 LLM + messages) | 一个全新 agent |
| 谁在执行 | 工具 executor | 新一轮 LLM 调用 | 新一轮 LLM 调用 |
| 生命周期 | 短(工具一次调用结束) | 短(派一次跑完销毁) | 长(教学版限 10 轮) |
| 同步 / 异步 | 异步(daemon thread) | 同步(父等子返回) | 异步(daemon thread) |
| 父是否阻塞 | 不阻塞,立即拿 placeholder | 阻塞,等子 agent 结果 | 不阻塞,立即拿”已派出” |
| 通信方式 | 单向 — 后台→父 (<task_notification>) |
单向 — 子→父(只回 last text) | 双向 — MessageBus 文件邮箱 |
| 能否多个并行 | 是 | 否(父 spawn 时阻塞) | 是 |
| 能否互相通信 | 不能 | 不能 | 能(teammate 之间能 send) |
| 典型用途 | 慢命令(./mvnw test) |
“分析 X 模块,做完告诉我” | “重构后端 — 多 agent 长期协作” |
| 能调用工具 | 不能(它就是工具) | 能(白名单子集) | 能(白名单 + send_message) |
人多力量大。遇到一个很大的任务时，从 Java 程序员的思路来看，可以多来几个分布式 Agent 来协同处理问题。
还有一个核心问题，多个Agent 之间怎么通信呢？
Background task 和 Subagent 都是单向通信：父向子安排工作后，子完成后单向地向父汇报结果，中间没有交互。
Teammate 之间是同事关系。双方之间通过 MessageBus 进行双向通信。
MessageBus 基于文件形式，Agent A 告诉 Agent B 应该干什么，Agent B 告诉 Agent A 我完成了。
AI in Harness（二）
书接上文
Error Recovery - 从错误中恢复
让 agent loop 在面对 LLM 三类常见故障(输出截断 / context 太长 / 后端过载)时自我恢复,而不是把异常一路抛回出去。
对于一个 Java 程序员处理异常那就太熟悉不过了。给 LLM 的调用方法加上 try catch。
目前最常见的错误，输出太长，输入太长，调用太快，模型压力太大。
输出太长：
- 第一次:把
max_tokens从默认 8000 → 升级到 64000(escalated),丢掉截断的输出,重新跑这一轮。模型重生成,通常这次能说完 - 第二次还截断:已经 64k 还说不完 → 真的需要”分两次说”。append 截断输出 + 注入
Continue.user message,让模型续写 - 超过
maxRecoveryRetries=3次 continuation:放弃,Fatal
输入太长：
- 可以直接调用
reactive_compact压缩模式。使用比较激进的压缩模式，只保留最近的若干条消息。
调用太快、模型压力过大：
- 调用 LLM 的时候才用指数退避的方式重试。若干次后依然报错，则抛出异常。
AI in Harness（一）
AI in Harness（一）
最近系统性地研究了一下 Claude Code 的实现，作为 Java 程序员写了一个开源的 Loop-based Agent Harness 框架。从工程的角度，以 Java 语言构建一个 Harness 的学习框架，理解 Harness 实现的技术细节。
从”写提示词”到”设计循环”再到”驾驭循环”
在使用 AI 的初期，你是否遇到过这样一个场景。写一个提示词，AI 回复一次，然后人工评估 AI 的结果，修改提示词，重新再向 AI 提问。这个场景中人是 Loop 中的一个环节，人的效率决定了 Loop 的效率。
Loop Engineering 被提出。Loop 的核心是人设定目标，系统自动完成”执行-观察-评估-修正”的闭环，直到任务完成。人从”指挥者”变成了”系统设计者”。但是 Loop 带来了新的问题，Loop Engineering 解决了 “AI 能不能自己跑”，但没解决 “AI 能不能跑得久、跑得稳、跑得安全、跑得起”。
为了解决以上的问题，Harness Engineering 被提出。在 Loop Engineering 基础上增加了上下文工程、工具设计、权限管控、记忆管理、上下文压缩等能力。
《SRE google 运维解密》读书笔记 （一）
新财年换了领导，管理风格也有一些区别。在团队内增加了一个 SRE 的职位。这一财年我将会承担一部分 SRE 的工作。
之前作为开发者，总的来说从开发的角度来思考系统的稳定性。现在需要从更高更全面的角度来思考和理解站点的稳定性。上网研究了一番，SRE 是 google 的一个职位同时 SRE 也是一套 google 总结出来的站点稳定性的方法论。所以找来了 《SRE google 运维解密》。这本书成书比较早，里面有些章节介绍的技术栈可能过时。具体我也不了解 google 内部是否还在使用。但是方法论还是很合理、科学的。
一直以来我工作过的团队对于风险的态度都是，预防和杜绝。但是在这本书里面，google 对于风险的态度就变成了管理，合理使用，甚至利用风险来保证项目的迭代。