一个移动开发者为什么要公开转型
我从 iOS 开发起步，iOS 至今仍是我每周都在写的东西。一路走来工作范围横向扩展过——Android、Vue.js 前端——但移动始终是重心。我们的一款 app Second Brain 从上线起就在生产环境的 Swift 代码里调用 Claude API：Haiku 与 Sonnet 之间的模型路由、基于 URLSession 的流式输出、用 Apple Foundation Models 做端侧分类。（集成细节我写过一篇文章，英文。）
AI Agent 工程师构建的是这样一种系统：模型自己规划、调用工具、观察结果、循环迭代直到任务完成——而 app 开发者做的是把单次模型调用集成进产品。我不是从零开始，但"调用模型"和"构建 agent"之间存在一道实实在在的鸿沟，而整个行业正在向鸿沟的另一侧迁移。跨过去需要的是一套不同于做 app 功能的技能。
这篇文章就是我要走的地图，也是一个系列的第一篇：下面路线图的每个阶段，都会在我真正做完之后写成一篇深度文章——真实的代码、真实的成本、真实的弯路。这是学习日志，不是内容排期表。
移动开发的哪些能力可以直接迁移
我调研转型路径时最大的意外是：移动开发者的起点比大多数"学 AI 工程"的教程假设的要高——那些内容是写给 Web 和后端工程师的。想想你已经会的东西：
- 异步和流式是你的主场。Agent 的界面就是一条由部分结果、工具调用状态和中断组成的流。写过
AsyncSequence、Combine，甚至只是带打字指示器的聊天界面，你就已经在用这种思维了。多数后端出身的 agent 开发者最后才补 UI，而且补得很糟。 - 你早就在为失败设计。移动开发教会你：网络会消失、系统会杀进程、用户会在写入一半时强退。Agent 以完全相同的方式高频失败：工具调用报错、模型返回格式不对、某一步超时。重试逻辑、幂等性、优雅降级——直接迁移。
- 状态机。Agent 循环本质上就是状态机：规划 → 执行 → 观察 → 决策。管理过 app 生命周期和导航状态，这个形状你很熟。
- 成本纪律。自己付过 API 账单的移动开发者，带着一种多数新人没有的直觉入场：每次模型调用都有价格，架构决定单位经济是否成立。Second Brain 的整个定价模型就是由每用户 LLM 成本倒推出来的。
- Swift 其实是 TypeScript 的预科。这点很关键，因为 TypeScript 是 agent 生态两大一等语言之一（另一个是 Python，主流 SDK 两者都有官方版本），而它是 Swift 开发者上手最快的那个。强类型、可选值与可选链、
async/await、protocol 对 interface、到处都是闭包：写现代 Swift 的人，TypeScript 是两周的适应期，不是一门新语言。唯一真正的断层是 TypeScript 的类型在运行时会被擦除——没有 Swift 那样的运行时保障，所以生态依赖 Zod 这类 schema 校验器，工具入参尤其如此。我写过几年 Vue.js，但说实话 Swift 才是更好的跳板。
移动开发没教你的东西
可迁移的技能列起来让人安心，但真正构成转型的，是移动开发没有教我的那份清单：
- 非确定性是契约本身，不是 bug。我以前对接的每个 API 理论上都是确定的：同样输入、同样输出，偏差就是 bug，测试能抓住。模型把这份契约翻转了——同一个请求明天可能给出不同的答案。替代性的工程纪律是 evals：精心维护的测试集、打分运行、回归追踪。Evals 之于 agent 工程，就是单元测试之于 app 开发——只是整个行业还在摸索怎么写好它。
- Tool use 是原子。Agent 就是一个在循环中自行决定"调用你的哪个函数、传什么参数"、直到它认为完成的模型。其余一切（编排、子 agent、规划）都由这一个原语搭出来。把它吃透，比学任何框架都重要。
- 上下文工程（context engineering）。模型只知道上下文窗口里的东西。决定放什么进去——检索到的文档、工具结果、记忆摘要，以什么顺序和格式——本身就是一门工程学科，而且在移动开发里没有对应物。
- 一套新的安全模型。Prompt injection 和 SQL 注入同韵：数据里夹带指令。区别是这里没有参数化查询的等价物，也没有可靠的转义手段。如果你的 agent 能读邮件或网页、又能发邮件或写文件，你面对的是移动开发从未让你准备过的攻击面。应对方式是最小权限和人工审批关卡，而不是"消毒"输入。
从 iOS 开发者到 AI Agent 工程师的四阶段路线图
这是我承诺执行的路径。每个阶段都有一个具体交付物：能跑起来的东西，而不是"读过的东西"。时间预估按"一边全职做 app 一边转型"的节奏给出。总计大约两到三个月的业余时间可以做出第一个生产级 agent——而第四阶段永远不会真正结束。
| 阶段 | 重点 | 时间 | 交付物 |
|---|---|---|---|
| 1 | TypeScript 直调 API | 1–2 周 | 流式 CLI 客户端 |
| 2 | Tool use + MCP | 3–4 周 | 一个我每天在用的 MCP server |
| 3 | Agent 循环与编排 | 4–6 周 | 一个端到端替我干活的 agent |
| 4 | 生产化纪律 | 持续 | Evals、追踪、成本控制 |
阶段 1 —— API 直调（1–2 周）
用 TypeScript 直接调 Claude：多轮对话、流式输出、结构化输出、system prompt。这些我在 Swift 里都做过，所以这个阶段同时兼任我的 TypeScript 热身。
交付物：一个流式输出 Claude 响应的小型 CLI 工具，从我的 Swift 客户端移植。
关键资源：Anthropic API 文档和官方 TypeScript SDK。如果你和我一样从 Swift 过来，请求结构和我在 Swift 集成文章里写的完全一致，变的只是语言。
阶段 2 —— Tool use 与 MCP（3–4 周）
这是把你从"API 使用者"变成"agent 开发者"的阶段。先手写 tool use 循环：定义函数、让模型选择、执行、把结果喂回去。先不用框架——原始的通信格式你至少要亲眼见过一次。然后写一个真正的 MCP server。（MCP，即 Model Context Protocol，是连接 agent 与工具和数据的开放标准，如今几乎所有主流 AI 平台都支持。）
交付物：一个我自己每天在开发流程中使用的 MCP server。检验一个工具是否真实，就看作者自己会不会一直用它。
关键资源：Anthropic 的 tool use 文档、MCP quickstart，以及 Anthropic 的 Building Effective Agents——我找到过的最好的概念地基。写任何编排代码之前先读它。
阶段 3 —— Agent 循环与编排（4–6 周）
构建一个完整的 agent：任务分解、"规划-执行-观察"循环、拥有独立上下文的子 agent、失败恢复、以及知道何时停止。先手写一版，再用 Claude Agent SDK 重写一版——这个 SDK 与其说是框架，不如说是整个 Claude Code 的运行时（内置工具、上下文管理、子 agent、权限系统）以库的形式开放。对比让你看清一个完整 harness 买到了什么，而不只是一层循环抽象藏起了什么。
交付物：一个端到端替我完成真实周期性琐事的 agent。我的选题大概率是给这个网站做四语言文案一致性检查：它要对比英、中、西、日四个语言版本页面的结构和文案——正是那种繁琐、又需要一点判断力的活儿，agent 的用武之地。
阶段 4 —— 生产化纪律（持续）
一切把 demo 和产品区分开的东西：eval 套件与回归测试、追踪与可观测性（我们的 app 已经在跑零 SDK 的可观测方案，agent 把这个门槛抬高了不少）、成本与延迟预算、prompt injection 防御、权限沙箱。这是我的生产级 app 直觉最能复利的地方，也是公开的实战内容最稀缺的地方——这个系列最有价值的文章会从这里产出。
为什么移动开发者在 agent 工程上反而有优势
对移动开发者来说，战略上正确的姿势不是"离开移动去做 AI"，而是把移动延伸进 AI。
Agent 需要界面，而且它们会越来越多地生活在用户已经在的地方：手机上。未来几年真正有意思的架构问题是混合式的——端侧模型负责私密、即时、零成本的推理；云端 agent 负责重型推理。这个模式的一半我已经在生产环境发布过（Second Brain 里 Apple Foundation Models 做分类、Claude 做综合）。两半都发布过的人写的东西，我几乎没找到——这也是这个系列存在的原因之一。
还有一块洼地：MCP 有官方 Swift SDK，而从"发布过 app"的实战视角写"iOS app 连接 agent"的人寥寥无几。本系列后面会有一篇专门用 Swift 写 MCP server。
终局不是变成一个恰好会用 LLM 的后端工程师，而是成为既能构建 agent、又能构建其周边产品的人：端侧层、界面、同步、经济模型。
FAQ：成为 AI Agent 工程师
需要机器学习背景吗？
不需要。Agent 工程发生在模型之上：你通过 API 使用模型，构建的是围绕模型的系统——工具接口、编排、evals、成本控制。它更接近系统与产品工程，而非 ML 研究。统计背景对写 evals 有帮助，但先决技能是能把软件做出来并发布。
转型需要多久？
按上面的路线图，大约两到三个月的业余时间可以发布第一个真正的 agent。之后的生产化纪律（evals、可观测性、成本控制）是持续精进的，就像"会发布 app"这件事永远没有终点。
学 TypeScript 还是 Python？
都是一等语言，主流 agent SDK 两者都有官方版本。从 Swift 或 Kotlin 过来，TypeScript 上手更快，而且如果你的 agent 需要真正的界面，它是自然之选。Python 在数据和 eval 工具链上占优。选离你现有技术栈更近的那个，概念完全通用。
"AI Agent 工程师"是个真实的职位吗？
头衔还年轻、叫法不一——AI 工程师、agent 工程师、应用 AI 工程师——但角色是真实的：做 agent 产品的公司需要会设计工具、管理上下文、写 evals、让非确定性系统在生产环境可靠运行的工程师。
系列计划，以及关于时间线的说明
按学习顺序排列的计划篇目：
- 从 iOS 开发者到 AI Agent 工程师——本文
- 从零手写 Agent 循环：Swift 里的 Tool Use——裸写循环、不用框架：原始报文、五个坑，以及 prompt caching 实测
- 用 Swift 写一个 MCP server——连接两个世界
- 手写 agent 循环 vs Claude Agent SDK——一个 harness 到底买到了什么
- 生产环境中 agent 的 evals 与成本控制——带真实数字，接续我做过的 AI iOS 成本分析
现实的节奏是每三到六周一篇。
最后一个提醒："agent 工程师"是个年轻的头衔，今天的一部分工具两年后会显得过时。但耐久的技能——工具设计、上下文管理、evals、非确定性系统的失败处理——会比任何胜出的框架都活得久，这份路线图优化的正是它们。框架只是今年的语法而已。