一个架构实践里，最怕的不是“还没做完”，而是“系统边界已经糊了”。只要边界清楚，下一步该补什么、该在哪层补，都是清晰的。

一、第三次操作系统革命 行业正在形成一个共识：我们正站在操作系统演进的第三次革命浪潮上。 第一次革命发生在1970年代，命令行取代了打孔卡片，程序员可以用键盘与机器对话。第二次革命发生在1980年代，

普通人前端的10年成长实录。女儿出生与AI爆发同时到来，我从普通二本、内向自卑、技术中下，一路靠死磕问题成长为高级工程师，并在AI时代完成向Agent工程师的转型。

一、飞书消息任务流程分析 把整个系统想象成一个「餐厅」 1. 消息接收：「接单」 场景： 顾客在外卖平台下单 做了什么： 飞书服务器收到用户消息 通过 WebSocket 或 Webhook 推送给

一、AI能力的五个台阶 OpenAI在2024年提出了一个清晰的五阶段模型，这不仅是产品路线图，更是对AI能力边界的系统性定义： 阶段 核心能力 典型代表 人机关系 Chatbot 自然语言对话，知识

在多 Agent 系统里，上下文怎么传，决定了系统的稳定性上限、成本下限、以及排障时的血压。 最开始，很多团队把它当成「把聊天记录拼一拼」的问题。上线后就会这样的问题： 同样的输入，输出飘得离谱。这里

别再让 AI 当“一次性嘴炮”了：Skills 如何成为智能体的“操作系统”？难道之前的n8n mcp tool都被迭代了吗？？？？？？？？？

这两年大家一提 Agent，脑子里很容易浮现出一个“会思考、会规划、会调用工具、还会自我修复”的高级智能体。听起来很玄，但如果把那些花哨概念都剥掉，一个能跑起来的极简 Agent，其实没有那么复杂。

做 RAG 经常会效果不行，就算是把模型换了更大的，回答依然飘；把向量库换了更贵的，召回还是不稳；把 Prompt 改了很多版，效果依然起起落落。 RAG 的瓶颈大多不在「生成」，而在「检索」。检索做

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体： 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。 让上下文成本可控（To

当 Agent 做到一定复杂度，问题往往不在模型能力本身，而在上下文怎么给、工具怎么给、流程怎么控。同一套模型，有的团队能把它用成「能稳定交付的执行系统」，有的团队只能得到「偶尔灵光一现的聊天机器人」

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

做 AI Agent，跑起来很容易，简单点函数调用+几个最好的大模型，复杂一点，整合或「学习」一些开源的多 Agent 项目，也能跑起来。 但是如何真正要做到一个行业中去，把一个行业 Agent 做好

2025 年算是 「 AI Agent 元年」。各种 AI Agent 层出不穷，我们能看到的做得比较好的还是编程用的 Agent。 做垂直行业 Agent 最常见的问题是「行业 Know How 没

当下 AI 圈最热的话题之一，莫过于 Agent Skill。 最早的实践来自 Claude 中的一类“模块化能力”，随后 Codex、Cursor、OpenCode 等编程工具也开始跟进并支持。 越

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

行业 Agent 和我们常用的「通用聊天 Agent」不是一类东西。 行业 Agent 是要能解决问题的，而查资料只是其中一步，后面还要做判断、走流程、调用系统、校验结果、留痕、可回放。

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

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