从 ChatGPT 到 AI Agent：作为工程师的这两年
两年前，我只用 AI 来问问题。
今天，我编排多个编程 Agent。我通过 MCP 连接公司知识库。我在 iOS 应用中运行本地模型。我维护一个记忆层，让 Agent 能够协同工作。
我不是 AI 研究员。我只是一个不断进行实验的普通工程师。
这是我从聊天到 Agent 的心路历程。
Stage 1: 可靠性鸿沟 起初，AI 感觉像魔法。接着，它显得不可靠。 模型经常以极高的自信度提供错误信息。 我吸取了一个惨痛的教训：听起来合理的答案并不等于可靠的结果。
Stage 2: AI 作为合作伙伴 像 Cursor 这样的工具改变了一切。 AI 从独立的聊天窗口进入了我的代码编辑器。 反馈循环变得极其短促： • 描述一个想法。 • 生成代码。 • 运行并观察失败。 • 请求修复。 • 重复。
这降低了构建原型的成本。小想法不再死于环境搭建或配置阶段，它们能够真正走向终点。
我学到了上下文是关键 (I learned that Context is Key) 早期，Agent 会忘记之前的决策或破坏架构。 我不再专注于“提示工程 (prompt engineering)”，而是开始转向“上下文工程 (context engineering)”。 我开始为我的 Agent 编写严格的规则： • 遵循现有架构。 • 在修改代码前先解释计划。 • 未经询问不得删除文件。
我们不仅仅是在写更好的句子，我们是在为这个概率系统构建一个稳定的环境。
Stage 3: 超越聊天窗口 我从网页端聊天转向了 API 和本地模型。 在桌面端运行模型很容易，但在移动应用中集成模型却很难。 突然间，我必须解决真正的工程问题： • 模型大小与内存占用。 • 启动延迟。 • 离线执行与设备兼容性。
Stage 4: Agent 驱动的工作流 重心从“编写这个函数”转向了“理解这个代码库并完成这个目标”。 我也开始使用 Model Context Protocol (MCP)。 我为公司的知识平台构建了 MCP 集成。 现在，Agent 可以访问公司十年的数据。 挑战也从模型智能转向了系统设计。
我最大的感悟： • 编码更容易，但工程更难。 • AI 处理实现，但你必须负责判断。 • 你需要精确地定义目标并验证假设。 • 多智能体协作需要一个记忆层，以便智能体可以在无需重启的情况下移交任务。
AI 让实现变得廉价。这意味着实验的成本几乎为零。真正的挑战在于决定哪些想法才真正值得去构建。
可选学习社区：https://t.me/GyaanSetuAi