架构和远方

随着 AI 编程在团队越来越普及，猛然发现一个正在变得「习以为常」的变化：以前遇到问题，第一反应是问同事或 Google；现在第一反应是问 AI。

挑一个你们团队最常做、步骤最清晰、但最浪费时间的任务，把它完整写成一个 Skill，再把现有系统封装成一个 Workflow。 这两个拼起来，基本就是你们自己的第一个「行业 Workflow + Ag

围绕 ComfyUI，大家讨论最多的是节点、工作流、算力这些，真正去看缓存细节的人其实不多。但只要你开始在一台机器上堆多个模型、多个 LoRA、多个 workflow，缓存策略就会直接决定这几件事：

最近 DeepSeek 的 OCR 论文里有个有趣的想法：用光学压缩来模拟人类的记忆遗忘机制。 这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点：距离越远，信息越模糊。一小时前的事记得清楚，

做 AI Agent 产品这段时间，最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI，但现实的技术约束让我们不得不妥协。 但这未必是坏事。工作流让 AI 变得可控、可靠、可用。

AI Agent 的发展还处于早期阶段，现在下结论还为时过早。但有一点是确定的：那些能够深入理解客户需求，扎实做好工程实施，持续优化产品体验的公司，最终会在这个市场上站稳脚跟。

AI 改变的是编程的方式，不是编程的需求。就像高级语言没有消灭汇编程序员，框架没有消灭底层开发者，AI 也不会消灭程序员。它只是给了我们一个更强大的工具，让我们能够解决更复杂的问题，创造更大的价值。

最近仔细看了 LangChain 的 Lance 和 Manus 的 Pete 的视频，主题是构建 AI 智能体中的上下文工程。这次分享没有那些空泛的理论，全是在生产环境中验证过的实战经验。 我结合自

AI Agent 持续火爆，不仅仅是产品上，在融资市场也同样火爆，各种产品都在往上靠。但对于 AI Agent 该如何架构，有人关注，但少有人刻意去了解和分析。一些常见的问题有：如单个 Agent 搞

简单来讲，AI Agent 实现的的大逻辑就是一个大的循环 + 获取上下文 + 不停的 LLM 调用 + 工具的调用。 那么一个关键问题就出现了：这个循环什么时候应该停止？如果处理不当，Agent 可

老家。 酒后！ 去年的所有文章有 90% 以上的内容和代码都是 AI 写的。这篇总结就不用 AI 了。 为什么用选择这个主题呢，原因很简单，因为刷视频的时候刷到了刘震云老师的一段话： 有点鸡汤

如果把 2022 年 6 月微软和 OpenAI 正式推出 Copilot 作为起点，AI 编程已经 3 年多了。 随着大模型的不断迭代升级，从 Copilot 到 IDE 下的 Cursor 入局，

简单来说，AI Agent 就是一个能够自主感知环境、制定计划、采取行动来完成特定目标的系统。 从架构的角度来看，又可以分为感知模块（包括状态上下文和意图上下文，而意图上下文是一个更难一些的问题），推

未来的 Agent 系统会走向何方？我相信会出现更多创新：自适应的隔离策略、跨 Agent 的安全通信协议、甚至是 Agent 专属的「虚拟操作系统」。

这让我想起一句话：在 AI 时代，真正稀缺的不是信息，而是注意力。上下文压缩就是在教 AI 如何分配注意力——什么该记住，什么可以忘记，什么需要随时能找回来。

对比 Gemini-cli、OpenManus 与 Manus 的上下文策略，可以看出不同系统在工程实现上的取舍哲学。Gemini-cli 采用实用主义的轻量分层设计，70/30 压缩策略既简单又高效

MetaGPT 里有个产品经理角色，负责协调其他工程师角色；AutoGen 支持 Manager-Worker 模式；Claude Code 更是明确采用了主循环引擎加子任务代理的设计。

看信息架构还是很多年前的事情了，大概是在 2010 年吧，有一本叫《Web 信息架构》的书，当时还在一线，想去做一个架构师，看到架构两个字就冲动买了下来。 有道是「买书一时爽，读书火葬场」 当然，这本

轻率地依赖技术是一种债务，而不是资产。是的，只有合理地使用技术，让这种技术服务于一个简单、清晰、连贯并且已经被深刻理解的概念时，技术才会成为加速发展的根本推动力。相反，当技术没有被合理使用，只是被当作

真正的高手不是掌握了多少技术，而是掌握了技术背后的原理。当你能够从第一性原理出发思考问题时，你就真正理解了技术的本质。 这条路可能不太好走，需要不断质疑、思考、验证。但相信我，这是成为技术专家的必经