如果把 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]昨天我写了一篇《用 LLM 构建程序化知识系统》，提出「记忆 · 知识 · 技能」三层架构。文章发出后不到 24 小时，两个重量级项目几乎同时进入我的视野——YC 总裁 Garry Tan 开源了 GBrain，EverMind 团队发布了 EverOS。
更巧的是，这两个项目恰好代表了 AI Agent 长期记忆的两条截然不同的技术路线：一条是"用自然语言指令驱动 LLM 自行理解"，另一条是"用工程架构确定性落地"。它们互为镜像，又互相矛盾。
[Read More]上周我让 AI Agent 帮我写博客。它干得不错——风格、结构、代码规范都对。因为我之前花了一个下午，让它读完我的 174 篇旧文，把写作风格提炼成了一份可执行的 Skill 文件。
第二天我让它再写一篇，它又对了。第三天，还是对的。到第四天，我发现了一件有意思的事：它自己改了 Skill 文件。它在"反模式"列表里新增了一条——“不要用’随着 AI 的发展’开头”——这是前几次我手动纠正过的，但我从来没有明确要求它把这个规则写进去。
那一刻我意识到，这个 Agent 已经不是在"执行指令"了。它在积累经验。
但紧接着我遇到了下一个问题：它记住了"怎么写文章"，却不记得"上次写了什么"。我让它写一篇关于 Agent 进化的文章，它洋洋洒洒写了 800 行——和三天前那篇重复了 60%。技能在进化，记忆在归零，知识没有沉淀。三条腿，只长了一条。
这个经历让我重新审视了一个问题：我们到底需要怎样的知识架构，才能让 Agent 真正"越用越强"？不是靠更大的上下文窗口，不是靠更贵的模型，而是一套程序化的记忆、知识与技能管理系统。
Karpathy 和社区最近的两个项目——让 Agent 一晚自主迭代 100 次实验的 autoresearch，和把任意文件夹变成可查询知识图谱的 graphify（25k+ stars）——也在指向同一个方向。
[Read More]上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。
我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。
这不是某个工具的 bug。这是当前所有 AI Agent 的共同困境：Agent 的记忆被钉死在了设备上。
[Read More]去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。
他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”
这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。
[Read More]前几天跟一个做 Agent 平台的朋友聊天，他说了一句让我印象很深的话：“我们花了半年调 prompt，好不容易让 Agent 在电商客服场景跑到了 90 分。结果客户说要扩到金融场景，我们一测——40 分都不到。”
我问他打算怎么办。
他苦笑：“重新调呗。再花半年。”
这个对话浓缩了当前 AI Agent 面临的最核心矛盾：我们造出了能力惊人但本质上是"静态"的系统。它在训练过的分布上表现惊艳，换个分布就翻车；它部署的那一刻就被冻结，遇到新场景只能等人类手动干预、重新训练。
这让我开始思考两个看似不同、实则紧密相连的问题：泛化（Generalization） 和 进化（Evolution）。
[Read More]上周有个做运营的朋友拿着一个 AI 帮他建的销量预测模型来找我，特别兴奋：“你看，R² = 0.89，是不是挺准的？”
我看了一眼，模型确实跑得不错。历史数据拟合得很好，特征工程也挺合理——用了过去 30 天的销量趋势、星期几、是否节假日。
我问他：“下周要下一整周的雨，你的模型知道吗？”
他愣了一下。
我又问：“竞品下周搞 618 预热大促，你的模型考虑了吗？你们市场部刚换了投放渠道，从抖音换到了小红书，这个变量在哪？”
他沉默了。
模型没有错。R² = 0.89 是真的。但这个模型不知道自己不知道什么。更要命的是，用这个模型的人也不知道。
这就是我今天想聊的事：AI 让建模的门槛低了，但这不等于人人都能建好模。
[Read More]今天下午我做了一件听起来有点奇怪的事——让 AI 读完了我自己的 174 篇博客，提炼出写作风格，写成了一份可执行的配置文件，然后告诉它：“以后每次写文章就按这个标准来，写完还要自己更新它。”
它真的照做了。不仅生成了一份包含六大风格特征、两种文章模板、四个薄弱环节和改进路线图的 Skill 文档，还自动附加了一条"进化协议"——每次使用完毕后检查是否需要更新。
这不是 prompt engineering，也不是 RAG。这是给 Agent 建程序性记忆（Procedural Memory）。
很多人给 AI 配了知识库、写了几百行 system prompt，但用起来总觉得"不长进"。问题不在于模型，而在于记忆的结构。静态 prompt 是一次性指令，而可进化的 Skill 是活的——它会随着使用自动迭代、越用越准、越用越像你自己。
[Read More]之前写过一篇用 AI 把 VOC 变成自动化流水线，讲的是整条流水线的架构——采集、分析、路由、执行。反馈不错，但也有读者指出一个关键问题：中间的部分（分类、路由）其实相对好做，真正难的是一头一尾。
“头"是用户问题理解——用户说"页面打不开”，你能不能自动搞清楚是哪个页面、什么场景、能不能复现、根因是什么？
“尾"是自动验证——修完 bug 之后，你能不能自动生成测试用例来证明"确实修好了，而且没有搞坏别的东西”？
这两个环节恰好是 AI Native 流程区别于传统自动化的核心：传统自动化靠规则，处理的是确定性问题；AI Native 靠理解和推理，处理的是模糊性问题。这篇文章就把这一头一尾拆开讲透。
[Read More]想象你团队来了个新同事——聪明、勤快、知识面广，但对你们的业务一无所知。第一天上午你走过去说：“帮我整理一下那个项目的材料。” 没说哪个项目，没说给谁看，没说什么格式，没说什么时候要。
他大概率会交出一份正确但平庸的文档。你看了一眼：“这也太模板了。”
这不是他能力不行，是你没把活派清楚。
现在把"新同事"换成 AI。同样的场景，同样的结果。但大多数人的反应不是"我没说清楚"，而是"AI 不够聪明"。事实上，AI 落地的真正瓶颈不是模型能力，是任务委托能力——一项被严重低估的管理技能。
[Read More]