这篇文章发出来的有点晚了，但是还是想给今年做一些阶段性的总结
2025年7月提出 DeepAgent 的架构，给模型 plan, file, task(agent as tool) , think 等工具，写厚重的提示词
现在趋势上有些回到 CodeAct ，模型进一步对 code 的能力增强， claude 也出了一篇文档教育大家 Code execution with MCP
2025年10月 Manus/Claude 几乎同时提出渐进式披露的上下文工程概念, 并且社区快速跟进 langchain、codex
然后因为陆陆续续的各种各样的原因，一直没有心思去写 Mobile Use 相关的实践分享。
Mobile Use 当时的 Agent 相关的内容，基本上是跟随着当时社区上方案的进化而进化，年底了给事情做一个总结，输出一些自己对 Agent 相关的思考。
数字生活就是几个环境，shell 、browser 、pc桌面 、mobile ，让 Agent 操作这几个环境就是现在软件生态最大的变化。
因为现在各种 Agent 教程也非常的多，所以我分享具体的实现意义也不大，并且现在因为技术封装和进步，这项技术已经不是那么的"神秘"了。所以我打算分享一“流水账”，关于怎么一步一步跟着时代迭代的，听起来就当故事听听吧。现在其实有了 AI ，理解了技术本身再去实现已经花不了太多时间了，关键是具体场景的 Trade off 和 Evaluation，所以用这样的视角去分享文章我觉得是一个我觉得比较 ok 的方式。
我的视角主要是从一个普通的 Agent 开发者的视角，缺少了在训练侧的视角，我觉得从训练侧来讲一定视角是不一样的，Agent开发者的视角主要还是以社区和自己业务的经验出发，模型层的事情很难透传出来，相比较草台很多，如果有训练侧的同学看到有一些观点不正确的，欢迎直接指出。
进行过 Manus 的教育，大家逐渐知道 Agent 是什么，以及 MetaGPT 团队的 "OpenManus" 一夜复刻 manus
到这个时间点看，其实 Manus 对 Agent 的理解还是比较超前的，比 claude skill 更快的提出上下文渐进式披露的概念。
倒不是真的就一夜复刻被自媒体炒得那么“不堪”
之前可以说 cursor 、bolt.new 这类的 coding agent 已经爆发了，然后从这之后，GUI Agent 也开始有雏形了，manus 应该是首次融合了 长任务/GUI环境/写代码 的 Agent ，当时manus里面最初版本是俩模型 qwenvl2.5 和 claude
在这个时候，因为我之前一直在分享 Agent 相关的内容，正好缺人做这一块，被调到云手机 Mobile Use 开始开发了。我加入的时候，PaaS层已经把 mcp 的工具都做好了，云手机沙盒基建层也是已经能力都全面ok了。尤其是里面特别关键的一个链路就是从手机里截屏上传到tos，其实有这个链路 + adb 的就能干了。
然后这个时间点，我在这个 Mcp 基础上接着做了一些事情，当时只剩一周时间了：
Agent Runtime 框架搭建
agent 通信抽象( 本地 / 云端 )、流式输出
Electron 壳子整体
基本上我就是基于云手机 OpenAPI+串流 完成了一个 MobileUseAgent。
这一版本写完了后，当时用 Claude 去驱动的，我印象非常深刻，跑完一次 12306 购票，给我扣了 3$，Claude 3.7 真是我一点工程都没有，一点图像处理的事情都没做，就硬跑起来了。
后面又增加了qwen，qwen 唯一需要注意的就是，qwen 需要调整图片的padding，不符合28/32整数倍的图片没办法正确grouding，且 qwen 对 xml 格式的提示词 follow 还挺好，基本上没什么问题
跑通 qwen 后，展会同学说还是得上 UI-TARS
当时太急了，说要第二天要切 UI-TARS 上大会。但是当时没有 claude code，切提示词系统和模型以及ActionParser ，以及切完了后跑效果是否有那么好，不是那么快弄好的事情。
不过有了 qwen 的经验，针对 UI-TARS 有俩问题还是很快就通了
一个是切提示词系统 + ActionParser
一个是图片会被 Scale 至 1000*1000
UI-Tars 这个 Thought Action 的 提示词是真的很不好用，因为这会导致一个 ActionParser 解析的不稳定性，当时真的还好能 Cursor + TDD 一下，否则按古法编程写疯。
至于我觉得工程上适合的格式，可以参考这个文档 XML Tool Calls ，还是得走 XML or Function Calling
于是乎上了 UI-Tars 后，发现 UI-Tars 还是不好跑起来，0328 版本的 uitars 没有 0428 那么猛，感觉长任务还是不行。
于是就整了个让 Claude 操作 UI-Tars 的 Tool ，也算是现在常用的一个 Agent As Tool 的模式的雏形。
这一波就沉淀了两套提示词系统，XML 和 ActionText 和 Parser
两套提示词，XML(claude qwen)、Thought Action （UI-Tars）
4.17 大会结束 ，紧接着下一阶段的任务是跟着 agentkit 做配合发布解决方案，Mobile Use 上体验中心和代码模版，把本地代码云化。
因为某些原因吧，我们先是针对之后用 go 还是 python 还是 ts 争论了一番，最后用 python + langgraph 重写了一遍 mobile use
如果能重来我愿意删除 langgraph，为这个框架问题有许多反常设计
尤其是他那个 stream mode 和 command ，用的折磨。
当时社区还在发展，如果有现在的 deepagents ，可能最快的 demo 办法就是上 deepagents， 长期考虑还是走自建 Agent Runtime
但是其实回过头来当初有许多权衡，选择 python 主要还是从生态和开源的角度考虑，但是如果是从人力和后续 api 发展角度，是 golang 的话，在公司内会跑的更快，也许当初的很多后事就不是这样跑的了？
这里这件事情还是给我了一个很大的教训
在这个阶段里，其实本来 typescript 手搓的 agent runtime 已经差不多了，其实最大的时间损耗，就在和 langgraph 斗智斗勇：
奇怪的 stream-mode
没有火山的 ChatModel ，直接使用 ChatOpenAI 输出不了 Reasoning
因为 ActionParser 的问题，并没有用好 Langgraph 的 @tool
持久化逻辑需要满足体验中心安全需求，不能存储用户的 messages
然后这个阶段，Agent 的大的改动其实也不多，主要是在做服务化、Electron 迁移成 Nextjs，体验，接火山 IAM ，部署服务等事情。
然后这个时候 UI-Tars-0428 和 doubao-1.5-vision-think-pro-0428 出了，
其实 AgentLoop 就很简单这一版本：截图、执行 的循环，保留最后3张图作为上下文，增加Applist，优化提示词。
不过过程中还是沉淀了许多 case ，当时解起来还是挺有意思的，其实做 Agent 本质就是给 Agent 做工具。
Agent 能遇到的问题就是
AgentLoop (Context Engineer\Prompt)
模型
环境(Tool)
| 类别 | 问题 | 解决方案 |
|---|---|---|
| Mobile Sandbox | 高德地图的定位问题 | 依赖云手机的基建，可以读取 Client 端的地理位置传递给云手机沙盒风控问题，不定位成功，高德不给用 |
| 大量风控问题滑块或者人机交互 | 只能模拟真机，或者通过模型滑块，滑块也需要模拟人的滑动云手机Docker方案批量封号？深度拆解平台风控的12个致命检测点 | |
| 摄像头风控 | 这个简单的可以通过云手机传流解决，遇到彩色闪屏也解决不了 | |
| LongPress 没有，但是 模型一直觉得有 | 长按工具的缺失，要补齐模型的认知上的工具 | |
| 幻觉UI-Tars 很依赖那一套Grounding提示词 | 只能尽量和模型的训练保持一致，不行遇到幻觉补充兜底 | |
| 支付宝不支付 | 模型训练了不做金融操作，就算提示词里写了有时候也会遵循不支付 | |
| 即使加了 “注销 删除 支付 等敏感操作， 请使用 call_user 通知用户后再进行操作” 提示词，也会注销 | 这个当时没有解决 | |
| Context Engineer | 单独依赖 GUI 在翻页的时候容易直接下断言不翻页 | 增加 Listapp 工具：If the user wants to use some app, please use list_apps to check whether the current app exists. If it does not exist, use the 应用宝 to download it first. |
| UITARS会陷入死循环，不像 Claude 聪明的会找到一些其他的解决方案 | 对云手机环境提示词写清楚，并且补充MobileUse下的场景工具 |
在这个时候，我意识到，沙盒 + HITL (human in the loop) 尤其的重要，如果模型够强，甚至 Runtime 可以极其简单，只需要 构建环境(工具)和模型
甚至很多时候如果模型够强，给他一个 截图 和 ADB ，做好文件系统，我会觉得是不是一切都结束了。所有的内容都可以通过 AgenticRAG 或者 AgenticSearch 去做
类似coding agent 的 grep 和最近很快的 mgrep 和 grep as model
站在12月这个时间点，我觉得上面这种架构的 agent 可能只需要配合 CodingAgent 1 天 就做出个能跑的demo。
Agent Runtime
这个时间点社区也有一些经验分享
不要构建多智能体 Don't Build Multi-Agents
Claude Code 爆了，这个 Agent 实在是太颠覆当时的开发体验了
以至于现在大家有个暴论说， Claude Agent ADK 就可以替代所有的 ADK runtime 了
7.18 当时 Manus 发了篇文章 “AI代理的上下文工程：构建Manus的经验教训” 在这个文章中得到的了一些经验。
7.30 Langchain 开源了 DeepAgents
在这个节点上，我们正在做 adk
ADK 支持手机 Device 的抽象，愿景是对接所有的触屏设备，只需要对具体的Tool提供实现
希望是支持所有社区上 Agent Runtime 的 Loop 的各种功能
于是乎在当时 DeepAgent 的架构上，就变成了如下图的内容。
你会发现，在这个节骨眼上，基本上每周都有一个很新的概念出现，作为 Agent 开发者其实是非常充实且疲惫的。
SDK 发布了后， 用 AI 两个晚上就搞了个文档站，通过 单测+源码 产生的文档站，稍微 Review 一下其实用户就方便用了。
当时 AI 写的文档还是被 PM 批惨了，最终还是要人把控质量，我纯改文档改了一晚上
写文档站 AI Coding + Docs 很快。
后面把 DeepAgents 加上后，发现了一些有趣的事情，比如
doubao-1.5-thinking-vision-pro 对 file system 的理解就不行，不会主动调用这个工具，而 uitars-2 就可以很轻松的使用这个工具，这个增强是模型侧的增强。
增加了 todo list 后，doubao-1.5 thinking vision pro 有时候会输出并行的工具调用。
在这个时候，我们基于上面的发现，doubao-1.5-thinking-vision-pro 模型 可以很好的遵循连续工具调用。然后我们一直也苦于截图在 Workflow 中的硬性卡点， 新增了一个动态的截屏工具，给出对应的连续工具调用的模式，让模型自己主动决定什么时候应该截屏，提高了灵活度，减少了 workflow 的部分，更加 ai native 。
我们发现这样居然这样也能够 Grounding 准。
我一直以为破坏了 UI-TARS 的Grounding提示词可能就点不准了，因为最早0328的版本稍微有些提示词不对，就点不准过。
这之后当时觉得，好像我们有一点摸到了 GUI Model 溢出的能力，这种用法应该在训练的时候是没有考虑过的。
Agent Evaluation
这一块之前我们计划是打算把 Evaluation 给自动化，通过数据集 + 用户用例去驱动，然后评测 Agent 迭代（ Tool、模型、提示词、AgentLoop ）。做了一些探索，但是实际落下地，跑到生产上的还是没跑上去的。
Trace 的 Checkpoint 定义复杂，对 Agent 过程的标注和判断很耗费人力。
不同数据集给到的材料不同，Trace 的数据格式和内容的抹平很耗费人力。
大部分 Mobile 数据集的质量不高，都是面向模型的操作性质的为主，长任务场景贴切业务的少。
我们的精力只能探索一下 LLM as Judge
再之后我们准备开始做 API ....
最后还是有业务进来了，并且跑的不错，解决了他们的场景
运营同学自己写提示词和标准，不需要让研发去维护 RPA 代码。
大规模自动化，介入的人变少。
像这些场景甚至最早都不在我们想到的范围内，我感慨还是只有业务才能想到贴切自己的 agent 场景，只有业务才方便做评估，只有业务才有自己的 Ground Truth。
不过当时我的想法也有一些变化：
似乎做到这里，我们被手机的环境困住了，我发现，大部分场景的 Agent 的最终的目标，实际上应该是一个 All in one agent ，配备专家知识，可以自由的使用环境（PC、Mobile、Web、FS）。
模型的升级带来的工程的挫败感太强了。
All in One Agent = All in One Model + All in One Env
这里面有个几个非常关键的事情
这个时候恰巧团队发生了架构调整，也是因为作为年轻人的一些冲动和彷徨，做了一些选择。
9月份很火的一篇播客 openai 姚顺雨的访谈和他的文章 The Second Half，里面也提到关键的两个主题，Evaluation 和 Env (评估和环境)
姚顺雨之前讲 Coding ↔ GUI ，会是一个融合的过程。之前看到 ui-tars2 的论文后再听到他讲这段话，这一定是一个很重要的事情。
上下文工程的范式几乎有点确定 Manus Context Engineering
Manus 发了一篇分享，里面提到了 三种 context engineer 的实践
这完全就是为 文件系统 构建的一套上下文实践。
Context Reduction、Context Isolation 、Context Offload
我觉得基本上就是对单 Agent Loop 的终结了，
Context Reduction 的提出让我们知道了 FileSystem 的工具的可逆压缩，以及token超出窗口的不可逆压缩。
Context Isolation 告诉我们 子Agent 和 Agent as Tool 的抉择
Context Offloading ，紧接着 Claude 立刻提出了 Skill ，就是对 Context Offloading 的规范化教育。把上下文卸载到沙盒中。
至此，我觉得，可能最终所有的 xxUse Agent ，都是一些 Skill 配套自己的沙盒环境就行了，真正从工程上有一种 All in One Single Agent 的雏形了。
发生了这么多事情，又因为个人兴趣原因，我也是因为想去下面探探 The-Second-Half 的其中一环：
All in One Agent 需要一个 All in One 环境
最终模型会吞噬工程工具，你做的任何的工程优化有可能再过三个月都是马拉火车。
引用一下 charles 的 tweet
真是轰轰烈烈一年啊，我没有经历过移动互联网时代，但是在这个 Agent 时代里，感觉每周都有新东西出现
新的 Agent 时代，持续做事，总会有结果
