9 月的一个深夜，我在翻 blog2 仓库里的一个文件，翻到有点不舒服。
skills/hugo-blog/SKILL.md，版本号 3.4.0，1078 行。第一次写它的时候只有几十行。中间模型换了好几代，这个文件一行没删，只加。加进去的每一行背后都是一次真实翻车——「Wan2.7 的 prompt 里不要写中文」「Gemini 的 landscape 必须是 1280x896，小了直接返回 400」「加粗标记内侧不能有空格」。
不舒服的点在这里：让我踩下这些坑的那几个模型，现在一个都不用了。但这 1078 行，一行都没作废。
我盯着它看了很久，意识到自己看的不是一个文件，是一条 loop 的沉淀物。
然后一个念头冒出来：模型训练是一个 loop，Agent 是一个 loop，人生也是一个 loop。 三个 loop 的结构完全一样——行动、观测、评估、更新。区别只有三条：反馈延迟多久、单次迭代多贵、状态能不能跨轮留下。
9 月初，我的数字员工「涌现」在一周里掉了三次链子。
它每天早上八点跑一轮「早读」：读公众号后台、读 GA、digest 小红书、更新 token 消耗、读 aibase——五步，预算一小时。8 月 31 日、9 月 2 日、9 月 5 日，三次吃了同一个兜底。前两次重启了事，第三次我让 opencode 做了一轮十五分钟的验尸：模型网关的机器名，被 /etc/hosts 里一行陈年映射和 DNS 搜索域联手坑了——解析结果里混进一条不通的 IPv6 路由，我常用的工具个个有回退所以毫无察觉，Agent 的运行时没有回退，当场死亡。整个排查过程我写成了 谁停掉了数字员工的早读。
事后回想，我当时的感受不是恼火，更接近于交学费的踏实。这个「早读」场景，技术上毫无炫技之处——定时任务、抓取、摘要、发消息，任何一个传统后端工程师一天就能搭完。但正是这个普通的场景，在过去几个月里每天给我生产真实的执行、真实的失败、真实的修复。我对 Agent 工程的大部分真实认知，不是从论文和 demo 里来的，是从这条 loop 里长出来的。
这让我越来越确信一个判断：Agent 应用工程师的核心竞争力，不是会不会调 Prompt、接 MCP、做 RAG，而是能不能建立一个真实的、持续运行的 Agent Loop。 而在选择做什么项目时，我会把一个指标放在非常靠前的位置：这个场景每天能给我多少次真实的执行反馈。
如果把 Agent 拆解成一个公式，最简单的表达就是：
Agent = Model + Harness
Model 负责思考、推理、决策；Harness 负责循环控制、工具路由、状态管理。过去一年，社区的目光几乎全部聚焦在 Model 上——谁的能力强、谁更便宜、谁上下文更大。但 Anthropic 工程团队最近发布的 Managed Agents 架构文章揭示了一个被忽视的事实：
“Harnesses encode assumptions about what Claude can’t do on its own. Those assumptions go stale as models improve.”
Harness 编码了关于"模型做不到什么"的假设，而这些假设会随着模型能力提升而迅速过时。一个更有趣的推论是：模型越强，Harness 的设计就越重要——因为越强的模型需要越精密的控制结构，才能把能力转化为可靠的产出。
这篇文章从 Anthropic 的工程实践出发，拆解 Agent 架构的核心设计模式，以及"面向未来的 Harness"到底长什么样。
[Read More]在AI辅助编程的时代，Claude Code等智能代码助手已经成为开发者的得力助手。但你是否好奇过：为什么Claude Code能够自动发现并修正生成代码中的错误？这背后的"Agent Loop"机制究竟是如何工作的？本文将深入剖析Claude Code的自动修正原理，并分享Agent Loop的最佳实践。
[Read More]