App 工程师的终结：为什么未来十年属于 Agent 构建者

历史总是喜欢押韵，而且通常发生在我们最安逸的时候。

回想一下 90 年代末。如果你懂得如何把 HTML 和一点点 Perl 或 PHP 拼凑成一个能跑的网站，那你简直就是个巫师。你是 Web 工程师，世界尽在你的掌握之中。你亲手搭建了互联网的门面。

快进到 2009 年。iPhone 刚刚撬开了新世界的大门。突然间，没人那么在乎你的静态网站了。所有的能量都转移到了 Objective-C 和 Java 上。如果你是移动应用工程师，你就是在书写未来。你在构建人们装在口袋里的工具。

现在，看看 2024 年。空气似乎又变得稀薄且静止了。应用商店已经饱和；Web 领域拥挤不堪。但在平静的表面之下，一场地壳般的变动正在发生。我们正在离开“界面（Interface）”时代，进入“智能体（Agent）”时代。

在接下来的十年里，最有价值的头衔将不再是“全栈开发者”或“iOS 工程师”。而是 AI Agent 工程师。

新的底层巨变

这不仅仅是另一场框架战争，也不是要学一门新的编程语言。这是关于谁在做这项工作的根本性转变。

在过去的二十年里，软件工程的核心是构建清晰、确定性的路径供人类点击。你做一个按钮；人类点击它；代码执行一个函数。人类是大脑；软件是肌肉。

这种动态正在发生翻转。

在智能体时代（Agentic Era），软件提供大脑。你的工作不再是构建让原本人类点击的按钮。你的工作是构建一个“数字员工”，由它来决定何时点击按钮，或者更好的是，它能意识到根本不需要这个按钮。

我做产品已经超过十年了，我能感觉到脚下的土地在移动。如果你今天能写出一个 Agent——一个为你服务、自动化你的工作流、或者服务你的客户的 Agent——你就拥有了和 1999 年那个刚学会如何把生意搬上网的孩子一样的杠杆。

但这里有一个残酷的真相：如果你拒绝学习这个，如果你坚持只写纯确定性的代码，你就有可能成为桌面出版时代的排字工——在这个新时代里变得无足轻重。

为魔法祛魅：工具与上下文

当人们听到 "AI Agent" 时，他们脑海里浮现的是“天网”或者某种极其复杂的神经网络架构。让我们拨开迷雾。

构建 Agent 不是魔法。它是工程。归根结底，它只关乎两件事：工具 (Tools) 和 上下文 (Context)。

我发现大多数开发者把这事想得太复杂了。他们以为需要自己训练模型。其实不需要。Claude、GPT-4、Llama 这些模型已经足够聪明了。你的工作是给它们装上双手和记忆。

1. 工具（给模型装上双手）

大语言模型（LLM）只是一个“缸中之脑”。它能思考，但无法触碰世界。“Agent” 仅仅是一个被赋予了访问 API 端点或 CLI 命令权限的 LLM。

你告诉模型：“这里有一个叫 list_files 的工具。这里有一个叫 read_file 的工具。这里有一个叫 send_email 的工具。”

2. 上下文（给模型指明方向）

然后你定义角色。“你是一名高级 QA 工程师。你的目标是修复这个代码仓库中的类型错误。”

就是这样。这就是核心循环。

如果你用过 Cursor 或 Claude Code，你就见过它的实际运作。你不需要微观管理每一个编辑。你只说：“修复 utils.ts 里的类型错误。”

Agent 会思考：好的，我得先看看文件。 它决定使用 ls 工具。然后它决定使用 grep 或 read。它发现了错误。它决定编写修复代码。它运行编译器来检查自己的工作。

这就是突破点。这不再仅仅是“聊天”了。这是一个决策循环。模型正在选择拿起哪些工具来解决你交给它的问题。

从聊天机器人到决策引擎

在过去两年里，我们一直被困在“聊天”阶段。我们像对待一个聪明的图书管理员一样对待 AI——我们问一个问题，它给一个答案。

那个阶段正在结束。

智能体阶段的核心是 执行 (Execution)。这意味着不再把 CLI 看作是你打字的地方，而是把它看作是模型的游乐场。

想想这对创业公司意味着什么。过去，如果我想建立一个处理客户退款的服务，我需要构建 UI、后端、数据库，并雇佣一个支持团队来点击按钮。

今天，我可以写一个 Agent。我给它访问 Stripe API 的权限（工具）和我们的邮件历史（上下文）。我给它制定一个策略：“如果用户在 7 天内表示不满意，就退款。” Agent 读取收到的邮件，判断是否符合标准，触发 Stripe 退款工具，并起草回复。

不需要 UI。不需要工单队列。只需要一个目标和一套工具。

构建 Agent 的“混乱中间态”

我不想在这里描绘一个乌托邦。过去六个月我一直在构建 Agent 的战壕里摸爬滚打，让我告诉你：这事儿很乱。

传统编程是逻辑的。如果 X 则 Y。它要么工作，要么报错。

Agent 工程是概率的。你构建了 Agent，给了它工具，有时它却决定用锤子去开窗户。有时它会产生幻觉，编造一个不存在的参数。

这正是新技能树的所在。

成为一名 AI Agent 工程师不仅仅是写 Python 脚本。它是关于：

• 提示词工程即架构 (Prompt Engineering as Architecture)：设计系统提示词来约束模型的行为。
• 评估驱动开发 (Eval Driven Development)：你无法为创造力编写单元测试，所以你需要构建评估管道来衡量 Agent 完成任务的成功率。
• 工具设计 (Tool Design)：创建足够“干净”的 API 接口，让模型能够理解而不会感到困惑。

我见过 Agent 陷入死循环，试图修复一个由它自己制造的 Bug。我见过它们自信地删除了错误的文件。这就是现实。但解决这些摩擦点，正是价值产生的地方。

实战建议：如何从今天开始

如果我今天从零开始，或者想要转型我的职业生涯，这正是我会做的：

1. 停止构建 GUI：至少在你的副业项目中。尝试在没有前端的情况下解决问题。你能只用 CLI 和 LLM 解决它吗？
2. 学习接口协议：理解 OpenAI 的函数调用 (function calling) 或 Anthropic 的工具使用 (tool use) 是如何工作的。这是 Agent 时代的 TCP/IP 协议。
3. 做一个“实干家”而不是“空谈家”：不要做一个回答你日历问题的机器人。做一个能管理你日历的机器人。赋予它删除事件的能力。去感受那种给 AI 写入权限的恐惧。那才是你真正开始学习的时候。
4. 掌握上下文管理：学习如何将正确的信息塞进上下文窗口而不使其溢出。RAG（检索增强生成）仅仅是个开始。

前方的机遇

我们将迎来这样一个未来：一个全副武装了各种专用 Agent 的开发者，能抵得上一家 20 人的创业公司。

创造的门槛正在降为零。但编排的门槛——即理解如何将这些大脑连接在一起——正在成为新的护城河。

十年前，你被雇佣来写代码。 今天，你被雇佣来架构那个写代码的系统。

列车正在驶离车站。你可以选择站在站台上紧紧抱着你的旧框架，或者跳上车，帮助铺设新的轨道。

让我们开始构建吧。