AI Systems & Product Engineering · Agentic Computing · 2027—2029
过去几年，我的关注点逐渐从 Web 工程、全栈开发延伸到 AI Agent。最初关心的是如何让模型调用工具、执行 Workflow；后来开始深入 Browser Automation、Agent Runtime、技能沉淀以及 AI 原生软件的实现方式。技术问题越来越复杂，我也越来越确定，自己感兴趣的并非某个框架，而是如何用新的计算能力，构建真正有价值的软件产品。
这种变化让我重新思考未来三年的职业方向。我不想离开工程一线，转成传统意义上的产品经理；也不希望职业身份被“前端”“浏览器”或某项短期热门技术锁定。我希望沿着技术专家序列继续成长：既能够设计复杂 AI 系统，也有能力发现问题、判断产品机会，并将想法交付成真实产品。
这篇文章是一次阶段性自我校准。我会明确区分三个容易混淆的东西：**职业身份是我想成为谁，技术判断是我选择研究什么，实践成果是我用什么证明判断与能力。**三者相关，但不能互相替代。
一、职业身份：AI Systems & Product Engineering
我给自己的职业定位是 AI 产品技术专家，英文能力方向为 AI Systems & Product Engineering；长期对标的国际岗位是 Staff AI Engineer / Staff Software Engineer (AI)。
Staff 是未来希望承担的问题范围，而不是今天已经拥有的头衔。我更倾向于 Individual Contributor（IC）的专家路径：可以影响技术战略、协调复杂工作，却不以正式带团队和人员管理作为身份的必要条件。
技术是根基：AI Systems Engineering
今天构建一个 Agent Demo 并不困难。真正困难的是把它交给真实用户之后：任务运行到一半中断怎么办？登录态失效怎么办？模型反复调用错误工具怎么办？多个 Agent 如何共享资源又不越权？结果如何验证？成本和延迟是否能接受？
这些问题无法单靠更强的 Prompt 解决，它们要求软件架构、分布式系统、执行环境、状态管理、安全隔离、评测与可观测能力共同工作。因此，我希望形成的深度不是“熟悉很多 Agent 框架”，而是能够设计、实现和持续改进生产级 AI 系统。
我仍然会投入编码和系统调试。产品技术专家需要保有足够的一线工程判断力，否则很容易只会描述方向，却无法判断技术代价和实现风险。
产品是方向：AI Product Engineering
同样，一个架构先进的系统也可能毫无产品价值。技术工程师常常习惯先看到某项能力，再寻找适合使用它的场景；但真正的产品思维应当能够反过来，先识别问题，再选择必要的技术。
我希望补强 Product Discovery、用户研究、产品定位、方案取舍、Human-AI Interaction 和端到端交付。能够讨论的不只是 How，还包括 Why 和 What：为什么值得做、什么才是关键需求，以及哪些功能即使能做也应该暂时不做。
这并不意味着要同时扮演所有产品与工程角色，而是希望具备跨越两边的判断力。**技术深度决定能实现什么，产品判断决定什么值得实现。**它们结合起来，才构成我想长期积累的职业壁垒。
二、对照国内与国际岗位，选择可迁移的能力
职业规划不能只根据当前项目制定。我对照过国内大厂的 AI Agent / AI 平台岗位，也研究过硅谷的 Product Engineer、Agent Infrastructure，以及东京国际化企业的 Staff AI Engineer、Applied AI Engineer、Forward Deployed Engineer 等方向。
这些岗位的侧重点不同。Money Forward 的 Staff AI Engineer 强调 Agent Runtime、Sandbox、评测与后端；OpenAI 的部分 FDE 岗位重视客户问题发现、AI 产品交付和沟通；Product Engineer 强调工程能力与产品判断；国内 AI 工程岗位重视架构和业务落地。
我从中归纳出四项相对稳定的能力要求。
**第一，解决复杂系统问题。**不能只完成局部功能，要理解系统边界、故障模式、性能和长期演进。
**第二，交付真实价值。**不仅展示技术可行性，还要通过产品体验、用户反馈或业务指标证明效果。
**第三，承担模糊问题。**高级专家不能总是等待别人给出完整 PRD，而应该能澄清问题、提出取舍并推动可执行的方案。
**第四，放大个人影响。**让架构、工具、方法或工程标准能够被其他人复用，而不只是自己写更多代码。
因此我不准备为了某个招聘标题，单独把自己训练成“Browser Agent Engineer”“OS Kernel Engineer”或纯粹的“AI PM”。具体技术专长必须深入，但最终应当能够迁移到不同产品形态、不同组织和不同工程问题中。
三、技术研究方向：Agentic Computing 与 FlyX
职业身份回答“我需要什么能力”，技术研究回答“我愿意把深度投入哪里”。这部分我已经有一个相对明确的判断：Agentic Computing。
我的假设是，AI 的发展不仅会给现有软件增加智能功能，还可能改变计算机的使用方式。过去，软件主要围绕人通过键盘、鼠标、页面和菜单逐步操作来设计；现在，Agent 已经能够接收目标、规划步骤、调用工具和操作软件。未来的计算环境，可能需要同时支持人和 Agent，而不是仅仅为人类操作提供界面。
这不是已经被证实的行业结论，而是值得持续验证的 Technology Thesis（技术战略判断）。我希望研究的是：当 Agent 成为计算资源的实际使用者，软件架构、执行环境和人机协作需要如何变化？
FlyX 在其中的位置
**FlyX 是我围绕 Agentic Computing 形成的个人技术体系与架构探索。**它不是简单的公司项目代号，也不等同于已经交付的产品，更不是职业头衔。它承载的是我对未来 AI 原生计算方式的一套假设，以及验证这些假设的实践方向。
在这一思路中，FlyBrowser 是当前比较具体的切入点：研究浏览器如何成为 Agent 的交互与执行环境，包括 Chromium、CDP、DOM/Accessibility/视觉混合感知、Browser Agent Runtime 和安全操作。
FlyOS 则代表向桌面与操作系统能力的延伸：研究 Agent 如何使用原生应用、文件系统、系统 API 和隔离计算资源。这里需要特别区分，研究 OS 级能力并不意味着已经构建了完整的操作系统，更不意味着必须从内核和驱动开发开始。
进一步往下，是可以被不同产品复用的 Agent Runtime、Computer Use、Identity、Sandbox、Checkpoint、Evals 和 Observability；往上，则是 AI Native Workspace 及其他人机协作应用，验证技术是否能够转化为更好的用户体验。
我希望沿着一条连续的问题链推进：浏览器能否成为稳定的 Agent 执行环境？这一能力能否扩展到桌面和其他计算资源？跨环境操作如何保持授权、安全、可恢复？这些技术是否真的能让用户更轻松地完成任务？
FlyX 的价值不是要求所有假设最后都成立，而是让我拥有一条可以持续检验、修正的研究路径。Browser 是当前入口，OS 是可能的拓展方向，Agent Runtime 与 Computer Use 是核心工程问题；真实产品反馈负责决定哪些判断值得继续。
四、能力模型：一条技术深度，两条扩展方向
为了避免规划变成无限增长的学习清单，我将自己的能力建设分成六个方面，但不会平均投入。
软件与系统工程
保持 TypeScript、Node.js 和 Web 工程优势，进一步强化 Python、后端系统设计、分布式任务、数据库、队列、云原生、并发与容错。补齐操作系统进程、IPC、文件和权限等基础。Rust 或 C++ 是解决特定系统问题的工具，不是必须同时精通的语言收集目标。
Agent 与 AI 系统
深入模型能力边界、Context Engineering、Tool Use、Agent Harness、规划与执行、状态和记忆。尤其要理解什么时候应当交给模型推理，什么时候应当使用确定性程序；如何避免上下文漂移、重复动作和错误的副作用。
评测、可靠性与安全
把 E2E Eval、Trace、Replay、故障恢复和权限治理作为工程基础设施，而不是上线前的附加检查。一个任务即使完成了，如果过程中执行了未经授权的敏感操作，也不应被评价为成功。评测体系必须同时衡量任务结果和系统行为。
产品发现与 Human-AI Interaction
学习用户访谈、需求判断、产品优先级、任务体验和关键指标。尤其关注 Agent 产品的交互：用户如何委托任务、理解不确定性、确认敏感操作、接管异常和审查结果。
端到端产品工程
能从一个问题出发，经过验证、原型、开发、发布、数据观察与迭代形成闭环。复杂系统经验可以通过工作积累；真正独立的产品判断，则需要有明确的决策空间和对结果负责的机会。
技术影响力与表达
练习架构文档、ADR、技术复盘、开源贡献和跨团队协作。提升英语技术沟通能力，做到能完整解释设计依据、技术权衡、失败原因和改进结果。高级专家的影响力不取决于标题是否响亮，而取决于判断是否被采纳，成果是否被复用。
五、2027—2029：三个年度侧重点
三年规划不是把技术、产品和影响力割裂到不同年份，而是三种能力同时发展，每年有所侧重。
2027 · Engineering Depth：向技术深处走
第一年最重要的是减少分散探索，抓住系统工程和 Agent Runtime 两个核心。我要从会搭建 Agent 功能，升级为能独立解释复杂执行系统的设计与故障。
工程上重点补强 Python 后端、分布式任务、持久化、异步执行、系统权限与云原生；Agent 方向重点研究 Runtime、Computer Use、Planner/Executor/Verifier、上下文工程和长程任务恢复。浏览器是重要实验环境，但评测不能只针对简单的网页点击，应覆盖登录态、动态页面、失败恢复和敏感操作确认。
我希望完成一个独立可维护的 Agent Runtime 实验系统，支持可追踪的任务执行、持久状态、基本隔离、断连恢复和可复现的 E2E 评测。它可以复用成熟的框架和执行组件，但关键边界与技术取舍必须由自己解释清楚。
同时启动一个较小的产品验证：围绕一类真实用户做访谈，确认问题是否足够重要，开发最小原型，而不是等待所有基础设施完善之后再谈产品。
验收结果： 一套运行时实践、一次深入的系统故障与性能复盘、一组对照评测数据，以及一个收到真实用户反馈的产品原型。
2028 · Product Ownership：向真实用户走
第二年，把“能完成任务”推进到“值得用户持续使用”。
我希望完成一次真正由自己承担关键选择的产品过程：从用户问题和现有解决方案出发，提出假设，做 MVP，发布给目标用户，根据留存、任务成功率、使用频率和满意度迭代。产品不必宏大，但必须有真实行为而不只是演示。
技术方面继续升级运行时的可靠性：让执行状态、权限、故障恢复、评测和监控能够支撑持续使用。结合 Computer Use 的研究，探索 Browser 与 Desktop 的共性抽象，同时保持对跨环境安全边界的敬畏。
对工作中的项目，我会明确区分“参与技术交付”和“拥有产品决策权”。前者可以证明复杂生产系统经验，后者需要通过真实的选择与结果证明。即使组织环境暂时无法提供完整产品授权，也应通过独立产品与开源实践补齐，而不是把参与某个产品当成自己已经拥有产品战略能力。
验收结果： 一个真实用户可持续使用的 AI 产品，两轮以上由反馈推动的迭代，明确的产品指标，以及能够说明取舍的技术与产品决策记录。
2029 · Technical Impact：向更大影响力走
第三年，目标是具备 Staff 级别的问题范围：能够识别系统性技术瓶颈，提出长期演进方案，对复杂工程结果负责，并通过可复用的能力扩大影响。
我希望能够独立承担一个重要 AI 系统领域的架构责任，在可靠性、成本、安全和用户体验之间作出有依据的权衡；能够把经验沉淀为 SDK、Runtime、评测体系、架构规范或开源成果；也能够和产品、设计、业务人员讨论为什么值得做，而不只是如何实现。
这个阶段不应只追求功能更多，而要检验工程投入是否产生了实质改善。需要用具体案例解释：面对什么不确定性、为何做出某个设计、如何验证方案、哪些指标改善了、还有什么代价与局限。
验收结果： 一个足以展示复杂系统设计的代表作、一项被其他人实际采用的工程能力、一个具有真实产品结果的案例，以及可以对外清楚表达的技术作品集。是否拿到 Staff 职级受组织和岗位影响，但能否承担这一级别的问题，应当有证据可查。
六、如何定期审视方向，而不是被计划绑架
我希望每半年检查一次。
技术上，是否遇到并解决了更难的系统问题？是否能够解释关键组件如何工作，而不只是调用接口？是否有可复现的成功率、恢复率、P95 耗时、成本或安全性改进？
产品上，是否真正接触用户？是否作出过重要的优先级选择？有没有因为证据而放弃一个原本很想做的功能？用户是不是愿意回来继续使用？
影响力上，是否有其他工程师采用过自己的架构、工具或方法？我是否能用一份清晰的技术文档，而不是依赖会议中的个人解释，帮助团队完成工作？
我也会保留“技术假设可以被推翻”的空间。倘若 Browser 不再是最有效的 Agent 执行环境，或者操作系统提供了更原生的 Agent 接口，那么 FlyX 的研究重点就应该调整。职业发展最值得保留的是问题求解与产品创造能力，而不是维护某个名称的正确性。
七、写在最后
过去，我常用学到了什么框架、完成了什么需求来评价成长。未来三年，我希望换一种衡量方法：能否独立判断什么值得做，能否设计可靠的系统，能否用真实数据证明产品与工程价值，能否让技术成果超出个人工作范围继续产生影响。
**职业身份上，我选择 AI Systems & Product Engineering，朝 Staff AI Engineer 的专家能力发展。技术研究上，我选择 Agentic Computing，并以 FlyX 作为自己的技术战略和实践体系。**二者不是同一件事：前者决定我需要具备什么能力，后者决定我当前把精力投入哪些技术问题。
2027 年更深入地理解系统，2028 年更认真地面对真实用户，2029 年让技术判断产生更广泛的影响。三条能力线始终并行，年度主题只是提醒自己不要失去重点。
我希望成为的，不是只会追逐最新 AI 工具的人，也不是脱离工程细节谈产品愿景的人，而是能够理解技术演进、识别值得解决的问题、构建复杂系统，并把技术创新转化为实际价值的产品技术专家。
Deep Technical Expertise · Strong Product Judgment · Real-World Impact
技术深度是根基，产品判断是方向，真实价值是最终标准。
微信- 支付宝
