架构和远方

最近仔细看了 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 信息架构》的书，当时还在一线，想去做一个架构师，看到架构两个字就冲动买了下来。 有道是「买书一时爽，读书火葬场」 当然，这本

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

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

当前不再是简单地“调教"模型说出正确的话，而是构建一个完整的信息系统，让 Agent 真正理解任务、掌握必要信息、做出正确决策。这种转变，预示着 AI Agent 正在从实验室的玩具，变成真正能够解决

人生很长，不必着急。但人生也很短，不能迷路。当我们学会站在终点看起点，很多困扰我们的问题都会迎刃而解。因为我们会发现，那些让我们焦虑的事情，在时间的长河里，不过是一朵小小的浪花。如当年韩寒

最近几天 Manus 的新闻不停的出现在我的信息流中，从 Manus 官方账号清空了微博、小红书上的所有内容，到裁员争议，据说将核心技术人员迁往了新加坡。一个从北京、武汉出发的纯正中国公司，最终选择了

在 GitHub 上搜索 "OPENAI KEY=sk-"，你能找到超过 2.5K 的代码记录。是的，是 2500+

毕竟， 空降兵最重要的不是会打仗， 而是先活下来。 而活下来的第一步， 就是搞清楚自己降落在哪里。

做 SaaS 产品这么多年，我发现权限控制是个特别有意思的话题。说它简单吧，很多团队都做得奇奇怪怪；说它复杂吧，掌握了核心原理后其实也就那么回事。 如果你是产品经理、技术负责人，或者正在做 B 端产品

代码是我们与机器对话的语言，但写代码的意义，永远是为了解决人的问题。无论工具如何进化，这一点不会变。 所以，继续写代码吧，带着思考去写，带着责任去写。让 AI 成为你的助手，而不是你的拐杖。