昨天半夜十一点半我从公司出来赶最后一班地铁手机震了一下是家里那台“值班 Agent”发来的推送“客户要的方案初稿已经跑完了三个候选版本在附件里请确认是否进入终稿优化。”我点了“确认”又补了一句语音“用第二版语气再正式一点”然后锁屏。等电梯的时候手机上又弹出一条任务完成最终稿已回传到飞书文档。第二天上午十点对方公司邮箱里准时收到了带完整签名的方案。这事放到一年前我干不出来。不是因为Agent不够聪明而是因为我必须在电脑面前、开着终端、盯着日志才能控制它。出门就等于断线。后来我把整套东西重新捋了一遍用手机当遥控器所有 AI Agent 都变成可以通过一条消息、一句语音随时调度的“远程工人”。这才算是真正把 AI Agent“下地干活”了。这篇文章把我从 0 到 1 搭建这套远程操控系统的完整过程写出来包括架构设计、Agent 本体实现、手机接入的三种方案、并发与稳定性处理、实际踩坑记录以及 2026 年国内 Agent 平台的一个简单盘点。1. 为什么要做“手机远程操控 Agent”这件事很多人把 AI Agent 做成了一堆代码跑在服务器上功能本身没问题但使用体验非常糟糕你在办公室电脑上启动一个任务然后只能干等。中途 Agent 需要你做个决定、确认一个动作对不起你得重新打开电脑连上 SSH。这种模式本质上还是传统的“服务器客户端”Agent 并没有真正融入你的工作流。我自己的核心诉求有三个第一是移动场景下的控制权我一天有一半时间不在电脑前机场、地铁、客户公司、咖啡厅到处都可能需要处理任务第二是人机协同的“审批节点”Agent 不是全自动脚本很多场景我不希望它自作主张比如发邮件、下单、部署上线必须经过我确认这个确认动作最好在手机上几秒钟就完成第三是多 Agent 的统一遥控我手上同时跑着好几个用途不同的 Agent一个做客户方案一个做数据监控一个做信息摘要。如果每个 Agent 都要一个独立 App、独立登录、独立看状态那就是灾难。手机远程操控的价值就是把这三种需求压缩到一个十几秒钟的交互里看到推送语音回复或点两个按钮完事。整个过程不需要打开电脑不需要看日志不需要理解底层是怎么调的模型。Agent 对我来说就像一个随时在线的外包团队我是那个只需要在关键节点签字的项目负责人。这也是“AI Agent 搭建”这件事真正走向实用的关键一步——Agent 不是跑起来就算完而是要能被人在恰当的时机“叫醒”和“接管”。2. 整体架构设计手机、服务端、Agent 三层怎么配合2.1 三层架构总览很多教程把 Agent 做成了一个大杂烩FastAPI 里直接调 LangChain中间再塞几个回调函数。Demo 跑得通一上真实场景就崩。我的做法是把系统严格分成三层各管各的。接入层面对手机端负责接收消息、校验身份、返回结果。我用的 FastAPI后面详说。调度层负责接住任务、拆解任务、记录状态、触发推送。核心是任务队列 状态存储。执行层真正的 Agent 逻辑用 LangGraph 做编排里面挂模型调用、工具调用、人机确认点。手机端和接入层的通信我用的是飞书自定义机器人也可以换钉钉或企业微信逻辑完全一样。用户在手机飞书里给机器人发一句“帮我查一下上周销售数据并生成日报”飞书把这条消息通过回调推到我的 FastAPI 服务服务解析后把任务交给调度层执行完再把结果通过飞书推送回去。这个架构看着简单但有一个非常关键的设计哲学接入层永远不阻塞等待 Agent 跑完。原因是 Agent 任务普遍很慢一次任务可能要调用好几次大模型动辄十几秒甚至几分钟。如果用普通的 HTTP 同步请求手机端早就超时了。我的做法是回调 URL 收到消息后立刻返回“任务已受理”然后把任务丢进队列Agent 跑完后通过推送通道把结果发给用户。手机端收到的是一个实时通知而不是等一个遥遥无期的 HTTP 响应。2.2 为什么选 FastAPI 作为服务层选型的时候我认真比较过 Flask、FastAPI、Spring AI 这几条路。Flask 很轻但异步支持比较弱我要做async并发和后续的 SSE 推送时体验不好。Spring AI 如果你是 Java 技术栈的老手它的官方脚手架也能做 Agent但社区生态和 Agent 编排能力目前还是偏新很多坑要自己趟不如 Python 这边趁手。FastAPI 的优势非常突出原生async/await性能足够强自动生成 OpenAPI 文档方便调试而且 Pydantic 的模型定义可以顺便给 Agent 的状态做校验。对于“手机远程遥控 Agent”这种需要大量短请求、回调、轮询的场景FastAPI 是目前实测下来最舒服的选择。我甚至用它的StreamingResponse接口做过 SSEServer-Sent Events推送就是服务器主动往手机推数据不用手机一直轮询。2.3 为什么用 LangGraph 做 Agent 编排这里要说一下为什么我不用纯 LangChain而是选 LangGraph。LangChain 的普通 Chain 是一条直线拿到输入调一次模型输出。但真实场景的 Agent 不是直线的它需要循环、分支、等待人工确认。比如我的方案生成 Agent流程是解析需求 → 查资料 → 写初稿 → 等用户确认 → 优化终稿。中间的“等用户确认”不是简单的 if 判断而是整个流程要暂停在那里等手机端的人回话再继续。LangGraph 的思路是用图来编排状态机节点和节点之间有边边上可以挂条件。我把“等待确认”做成一个特殊节点执行到这一步时把当前状态存起来push 通知手机然后挂起。手机回消息后从存储里恢复状态继续往下走。这让整个 Agent 从一个“一次性脚本”变成了“能随时打断、恢复的长跑状态机”。2.4 通信协议的选择HTTP 回调、WebSocket、SSE 怎么权衡手机和 Agent 服务之间通信我实测过三种协议分别适用不同场景。HTTP 回调最简单手机端发消息触发请求服务端处理完返回的结果通过推送通道再回给手机。成本最低调试最方便适合大多数异步任务。WebSocket适合需要实时双向通信的场景比如你在手机上盯着 Agent 一步一句生成内容。但实现复杂飞书/钉钉这类平台的自定义机器人不支持需要自己开发 App 或 Web 页面。SSEServer-Sent Events适合服务器向手机单向推送实时进展比 WebSocket 轻量得多。我给自己写的 PWA 管理页用了 SSE可以实时看到 Agent 每跑完一个节点就在页面上打一个勾。实际项目里80% 的需求用“HTTP 回调 推送通知”就够了剩下 20% 加个 SSE 看进度。上来就用 WebSocket 属于给自己挖坑。3. 从 0 到 1 搭建 Agent 本体一个可调度的“任务管家”下面用一个真实可跑的例子讲清楚 Agent 本身怎么做。我给它起名叫“任务管家”职责是接收一段自然语言消息拆解成任务调用合适的工具在关键节点等我确认最后把结果推送回手机。你可以把它换成任何具体领域的 Agent结构是一样的。3.1 需求定义和运行流程我定的需求很简单用户也就是我通过飞书发一段话比如“帮我总结一下这几个链接的文章然后发到我的邮箱”Agent 要做的事是解析意图识别需要哪些工具这里需要网页抓取和邮件发送。抓取链接内容总结成 500 字摘要。生成邮件草稿暂不发送等手机端确认。我点确认后发送邮件通知我结果。整个流程定义成 LangGraph 的状态机状态State我这样定义from typing import TypedDict, Optional class AgentState(TypedDict): task_id: str # 任务 ID贯穿全链路 user_input: str # 用户原始输入 intent: str # 意图识别结果 tool_params: dict # 工具参数 draft: str # 生成草稿 approved: bool # 人机确认结果 status: str # 当前节点状态3.2 定义状态图的节点和边然后是几个核心节点parse_intent识别意图collect_data调用工具抓取数据generate_draft生成草稿human_approve等待人工确认send_email执行发送。from langgraph.graph import StateGraph, END def parse_intent(state: AgentState) - AgentState: # 调用一个小模型解析意图比如识别出 summarize、send_email 等 state[intent] llm_extract_intent(state[user_input]) state[tool_params] extract_params(state[user_input]) return state def collect_data(state: AgentState) - AgentState: # 根据参数抓取页面内容做 Markdown 清洗 raw_text fetch_and_clean(state[tool_params][urls]) state[context] raw_text return state def generate_draft(state: AgentState) - AgentState: state[draft] llm_summarize(state[context]) return state def human_approve(state: AgentState) - AgentState: # 这里会真实触发一条手机推送阻塞等待用户回复 approved notify_and_wait_confirm(state) state[approved] approved return state def send_email(state: AgentState) - AgentState: send_email_via_smtp(state[draft], state[tool_params][recipient]) return state把它们挂到图上workflow StateGraph(AgentState) workflow.add_node(parse_intent, parse_intent) workflow.add_node(collect_data, collect_data) workflow.add_node(generate_draft, generate_draft) workflow.add_node(human_approve, human_approve) workflow.add_node(send_email, send_email) workflow.set_entry_point(parse_intent) workflow.add_edge(parse_intent, collect_data) workflow.add_edge(collect_data, generate_draft) workflow.add_edge(generate_draft, human_approve)这里关键的逻辑在human_approve之后怎么走用户确认了继续发邮件用户拒绝了直接结束。from langgraph.graph import START, END def after_approval(state: AgentState): return send_email if state[approved] else END workflow.add_conditional_edges(human_approve, after_approval, {send_email: send_email, END: END}) workflow.add_edge(send_email, END) app workflow.compile()3.3 人机确认节点是怎么做到“暂停等待”的这是整套系统的灵魂。human_approve不能真的让整个进程阻塞在那否则服务就玩完了。我的做法是把这个节点拆成两步当流程执行到human_approve时先从状态存储Redis里把当前task_id对应的完整状态序列化存起来然后向手机推送一条带确认按钮的通知。手机端用户点了“同意”或“拒绝”飞书会把结果回调到服务里的/agent/confirm接口。这个接口从 Redis 里把状态取出来把approved字段改掉然后调用 LangGraph 的app.update_state()从暂停的节点恢复执行。说白了就是把流程的上下文“物化”到 Redis等外部事件触发后再恢复。这比把整个进程挂起要稳得多服务重启了任务也能继续因为状态都在 Redis 里。3.4 从 0 搭建时踩过的工具链坑LangGraph 从 0 到 1 搭第一个项目时我踩过两个大坑提前说清楚能帮你省一个下午。第一个坑是 Python 版本。LangGraph 比较新的版本要求 Python 3.10如果你服务器上还是 3.8很多新语法比如TypedDict的NotRequired会被直接判错。我一开始用 3.8 跑旧版报错一堆后来重建虚拟环境装 3.11 才干净。第二个坑是状态共享问题。LangGraph 的 State 是节点间传递的但如果你想在一个节点里修改另一个节点已经写入的字段要注意字段类型是否兼容。比如我在collect_data里给state[context]赋值了但AgentState里没声明这个字段Pydantic 校验会直接拒绝。定义状态时把所有可能出现的字段都提前列好别偷懒。4. 手机端接入三种方案实测对比Agent 本体做好了现在把手机接进来。我把方案拆成三种分别对应不同需求场景实测数据都在下面。4.1 方案一飞书/钉钉/企业微信自定义机器人最推荐这是我主力在用的方案没有之一。飞书开放平台创建一个自定义机器人拿到 Webhook 地址和机器人密钥然后配置事件订阅。用户在飞书里给机器人发消息飞书会往你配置的回调地址发 POST。回调地址对应 FastAPI 的一个接口逻辑非常简单from fastapi import FastAPI, Request import httpx app FastAPI() app.post(/webhook/feishu) async def feishu_webhook(request: Request): payload await request.json() user_message extract_text_from_feishu(payload) # 解析飞书消息体 task_id submit_task(user_message) # 丢进任务队列立刻返回 return {code: 0}这个方案的好处是手机端完全零开发直接用飞书 App支持语音、文字、图片、按钮交互。飞书的消息里能带交互卡片我可以把“确认发送”“拒绝”做成卡片上的按钮用户点按钮直接触发回调体验非常好。注意一个关键细节回调接口必须公网可达。我用的是国内云服务商的一台轻量服务器配个域名加 HTTPS。飞书对回调地址有安全校验必须通过验证所以回调地址的路径和 token 要严格按照飞书后台的配置来。4.2 方案二Webhook 各类推送通道适合个人极简如果你不想用飞书这类 IM 工具可以用更轻的组合HTTP Webhook 接收消息 Server酱/Bark 推送结果。Server酱是国内常用的一个推送服务你注册后拿到一个 key用一条 HTTP GET 就能把消息推到你的微信上。Bark 是 iOS 上常用的开源推送工具原理类似一条请求推送到手机通知栏。这套方案的优点是极度轻量不需要配回调 URL 和加解密适合做个人小工具。缺点是完全没有“按钮交互”用户只能看结果想确认动作得靠回复特定关键词比如回“Y”确认体验粗糙一些。我用这个方案做过一个临时的评测工具纯验证想法阶段完全够用。4.3 方案三自建 PWA Web Push全流程可控如果你对数据隐私有要求不想走任何第三方平台可以自己做一个极简 PWA渐进式 Web 应用配合 Web Push 协议推送到手机浏览器通知栏。这个方案需要的工作量一个 HTTPS 域名、一个 Service Worker、一个 Web Push 订阅端点大概多花一两天时间。好处是彻底可控通知内容可以做到完全自定义UI 你想做成什么样都行。坏处是手机浏览器后台推送的可靠性不如原生 IM 应用比如 iOS 上的 Safari 在用户长时间不打开页面后通知到达会有延迟这个要注意。我的经验是如果用途是个人工具方案二就够如果要给团队内部用直接上方案一。方案三适合那些“我就是想自己折腾一遍底层”的人。4.4 三种方案的选型建议我整理了一个对比表方便你直接照抄方案手机端体验开发成本交互能力数据可控性推荐场景飞书/钉钉机器人优秀有卡片按钮低强支持按钮语音经过第三方平台团队协作、正式使用Webhook 推送通道一般只能看通知极低弱只能命令式回复经过推送服务个人实验、临时工具自建 PWA Web Push良好但后台不可靠中等中等可自定义 UI完全自主可控对隐私敏感的场景5. 并发与稳定性AI Agent 怎么扛住一波请求热搜词里有一个我特别想回答的问题AI Agent 怎么扛并发。这个问题问的人多是因为大家拿 Agent 当普通接口来设计一压测就懵。我把自己实测的经验和算法写在这。5.1 先算清楚Agent 的并发瓶颈在模型调用上普通 Web 接口的并发瓶颈是数据库/计算资源而 Agent 的瓶颈是大模型调用的时间和频率。假设你的一次 Agent 任务要顺序调 3 次 LLM每轮平均耗时 3 秒那么单任务耗时约 9 秒。如果有 100 个用户同时发起任务你可能直觉以为要“扛 100 QPS”但真实情况是这 100 个用户同时进来后系统同时并行跑 100 个任务流每个任务流内部都有一段阻塞在 LLM 返回上。所以核心结论是Agent 并发不是“请求越多越好”而是要控制任务并发数否则会把模型供应商的限流直接打爆。比如某模型 API 的限制是每分钟 60 次请求RPM你同时跑 50 个任务每个任务调 3 次模型一瞬间就 150 次请求超了模型服务直接给你 429。我处理并发的方式是引入一个限流信号量import asyncio # 控制同时并发的 Agent 任务数量比如最多 8 个任务同时跑 semaphore asyncio.Semaphore(8) async def run_agent_with_limit(user_input: str): async with semaphore: return await run_agent_task(user_input)这比一味增高服务器配置更有效因为 LLM 的硬约束摆在那。你单位时间能跑的任务数取决于模型接口的 RPM/TPM 限制跟你机器是 2 核还是 32 核关系不大。5.2 结构上拆成“快接口”和“慢任务”为了让手机端的体验不至于卡住我在 FastAPI 层做了两个接口/agent/run只负责接收任务、返回task_id立刻结束真正的 Agent 执行放到工作进程里。这样接入层永远不会阻塞哪怕 Agent 跑十分钟手机端也只会收到“任务已受理”的即时响应过几分钟再收到完成通知。架构拆开后接入层和计算层可以独立扩容。接入层是纯异步无状态的压测 100 并发毫无压力计算层受限于模型调用和多 Agent 调度。我的经验是接入层开 4 个 worker计算层开 2~4 个任务 worker再多边际收益就很小了。5.3 用 Redis 做任务状态中心远程操控 Agent 有一个隐藏需求你随时要知道“我的任务到哪一步了”。我引入 Redis 做状态中心任务每经过一个节点就把进度写进 Redistask:{task_id} { status: human_approve, current_node: generate_draft, steps: [parse_intent, collect_data, generate_draft], updated_at: 1735000000, message: 已生成草稿等待用户确认 }手机端发一条“查询任务状态”服务就去 Redis 读进度返回。这不光是为了展示进度更重要的是当进程崩溃、服务器重启后能从 Redis 恢复任务状态做到不丢任务。对于那些长耗时的 Agent 任务Redis 就是整套系统的“账本”。5.4 LLM 调用的稳定性策略大模型调用是整个链路里最容易出问题的一环。我踩过的典型问题有超时模型服务没响应、令牌耗尽Token 上限、限流RPM 超限、偶发 500。给 LLM 调用加三重保护用tenacity做重试遇到Timeout、429、500时自动重试最多 3 次指数退避。给每个模型调用加硬超时比如 60 秒没返回就当失败绝不无限等下去。在代码里对模型服务做熔断连续失败超过 5 次后暂停新任务入队等和服务商确认后再恢复。5.5 实测压测数据我用 Locust 对这套系统做过一轮压测先说压测条件一台 4 核 8G 轻量服务器Redis 在同一台机器模型调用用的是 mock每轮 sleep 2 秒模拟这样是为了测通路的极限。结果如下并发用户数接口成功率平均响应时间接收任务Agent 任务完成率备注20100%80ms100%轻松应对50100%120ms100%状态正常10099.8%200ms92%Redis 连接池打满部分任务排队20099.2%450ms75%出现任务超时需要扩展 worker结论是对个人或小团队使用的量级这套架构完全够用瓶颈在模型调用和 Redis worker 数量。如果你要扛更大的量建议上 K8s 自动扩缩容加上 Redis 独立部署。6. 实测效果与常见问题排查实录6.1 一次完整远程任务的运行记录我记录一次今天我实际跑的“任务管家”流程给大家一个直观时间线10:15:22 我在手机上给飞书机器人发语音“把这三篇文章总结一下生成一份竞品分析周报发到项目群。”10:15:23 服务端回调收到消息返回“任务已受理”飞书界面立刻出现一条“处理中”的卡片。10:15:24 任务进入队列parse_intent节点启动。10:15:26 意图识别完成识别出工具fetch_webpage、generate_report、send_to_group参数正确。10:15:32collect_data节点抓完三篇文章清洗成 Markdown。10:16:10generate_report节点生成 800 字竞品分析周报草稿。10:16:12 飞书推送卡片到手机“周报草稿已生成是否发送到项目群【确认】【修改】”。10:16:31 我看了眼内容点了“确认”。10:16:33send_to_group执行推送到项目群全程不到一分半。这个流程里我最满意的是中间那十几秒的“确认卡片”它给了人足够的控制感又不会让你守着电脑干等。6.2 高频故障排查速查表把我实战中踩过的坑整理成一张表方便你遇到问题时直接对号入座问题现象可能原因排查方法解决方案飞书回调一直验证失败回调地址没有公网访问 / Token 配置错误用 curl 手动 POST 测试回调地址看返回检查飞书后台“事件订阅”里的 Encrypt Key 和 Verification Token 是否和服务端一致任务提交后手机收不到推送飞书机器人未开启“机器人”能力 / Webhook URL 配置错在飞书后台“权限管理”里打开机器人权限给机器人开通im:message相关权限并重新发布版本Agent 卡在“等待确认”不动Redis 中任务状态丢失查看 Rediskeys task:*是否还在检查 Redis 的持久化配置开启 AOF服务重启后从快照恢复模型调用频繁被限流RPM/TPM 超过模型服务限制查看模型服务返回的 429 日志加信号量限制并发任务数配合指数退避重试手机端消息内容乱码飞书消息加密后未正确解密回调里打印 payload 原始数据对照文档解析确认对消息内容做了 AES 解密并处理了时间戳偏移问题6.3 我踩过的三个“独家电”坑第一个是飞书回调的“重试地狱”。飞书对回调有超时要求如果你 FastAPI 接口处理逻辑比较慢飞书会认为失败并重新推送同一条消息导致任务重复创建。我的解决办法是接口层收到消息后先查 Redis 里有没有相同msg_id的任务有就直接返回不重复入队。第二个坑是长任务丢推送。Agent 任务跑了 10 分钟推送的时候手机锁屏了那个推送可能会合并成一条或者延迟到达。我后来妥协了重要任务跑完后除了推送通知还会往飞书群里发一条完整归档消息这样就算推送丢了用户打开群也能看到结果。第三个坑是我一直犯懒把任务队列和 Redis 放在同一台机器上直到一次任务量大了之后Redis 延迟把队列消费速度拖垮了。现在我会对信号量、超时、连接池做针对性配置。别小看这些基础组件远程操控场景下它们任何一个小抖动都会表现为“我的 Agent 怎么没有反馈”。7. 当前国内 Agent 平台现状盘点与我的选择7.1 为什么要“自建”而不是直接用现成平台这个问题的答案很简单现成平台解决的是“从 0 到 1 快速做出一个 Agent 给用户体验”但很难解决“让 Agent 真正融入我自己的工作流”。我要的不是一个聊天式 Agent而是一个能被我的手机消息调度、能访问我公司内部文档、能通过 Redis 恢复状态、能复用我现有代码库的工具。这种“基础设施级”的集成只有自建才能做到。7.2 2026 年国内 AI Agent 平台及搭建工具盘点不过我也建议每个做 Agent 的人先花几天时间把国内主流平台摸一遍再决定要不要自建。我盘点了以下几类平台/工具类型适合谁我的评价扣子Coze无代码 Agent 搭建平台业务人员、快速原型验证搭建快插件生态丰富适合先跑通流程百度文心智能体平台无代码/低代码百度生态用户中文理解不错发布渠道多阿里云百炼低代码 API需要模型能力的企业模型种类多适合与阿里云服务集成Dify开源低代码平台想自建但不写代码的人可视化编排很强适合快速搭建内部工具FastGPT开源知识库问答知识库类场景在 RAG检索增强生成方面做得很扎实自研 FastAPI LangGraph全代码框架有开发能力需要深度定制的人最灵活适合做“远程操控”这种个性化场景我给新手的建议是先不去看“2026 年 AI Agent 产品盘点”这类文章而是自己上扣子或者百炼根据模板拖一个 Agent 出来感受一下意图识别、工具调用、工作流编排这些概念。有了体感之后再看自建方案你会清楚每一块代码到底是在解决什么问题。7.3 后续还可以扩展的方向我目前这套远程操控系统跑得很顺但它能扩展的边界还很大多 Agent 协同让“任务管家”在遇到自己搞不定的问题时把任务转派给其他专业 Agent比如数据分析 Agent、图片设计 Agent手机端只看到最终统一的结果。定时任务调度给 Agent 加一层APScheduler或CronJob让它定时跑日报、周报跑完推手机实现“无人值守”。语音交互扩展飞书本身支持语音转文字如果接入国产语音识别模型比如阿里、讯飞的接口可以让手机语音直接变成带上下文的指令。引入工作流审批比如“发送邮件给外部客户”必须二级审批手机端推送给两个人两人都确认才执行。关于有没有人用 Agent 做期货交易这个热搜问题我的看法是拿 Agent 做行情信息监控、策略信号提醒、定时抓数据并汇总成报告这些完全没毛病。但如果你打算让 Agent 直接自动下单我的建议是别。Agent 当前的可解释性和稳定性还没到能替你做金融决策的程度让它“帮你看盘”而不是“替你下场”是更合理的使用边界。最后分享一点实际体会整套系统跑了一个多月之后我最深的感受是远程操控 Agent 不是技术炫耀而是一种全新的工作节奏。以前我总觉得 Agent 是“跑在服务器上的代码”现在我觉得它更像是我的数字员工随时随地可以被我一条消息叫起来干活。中间那种“等确认”的交互让我保留了作为人的判断力而把大量重复劳动交了出去。最后再分享一个实用小技巧如果你用的是飞书机器人一定要把**“宽松模式”**开关调对。飞书后台有个“签名校验”选项如果开了你在本地或测试环境联调回调时会非常痛苦。我一般本地开发时关掉校验部署到正式环境再打开。别问我是怎么知道的调试回调的那天晚上我改了三遍签名算法才想起来是这个开关的问题。