一、先说结论Ultraplan 到底解决了什么痛点Ultraplan 可以理解为一种“远程规划模式”用户在本地终端发起一个复杂任务系统把规划阶段卸载到远程 CCR 容器中执行。本地终端不再被长时间占住远程端可以使用更强模型、更完整的代码副本、更长的探索流程最终把计划交给用户审批。它解决的不是“让 AI 写更多字”的问题而是“复杂任务前置规划太耗时、太占上下文、太占终端”的问题。过去本地 Plan Mode 在当前会话里顺序读文件、分析结构、写计划一旦任务很大终端就像被一个长耗时进程占住。Ultraplan 把这个重活搬走本地只保留触发、展示、审批和接管能力。这背后其实是一种非常典型的工程架构本地轻入口远程重执行中间靠状态机与轮询维持同步最后让用户决定远程执行还是传回本地。二、整体架构本地终端 CCR远程容器 浏览器审批从工程视角看Ultraplan 不是一个单点功能而是一条完整链路输入侧识别关键字命令侧检查资格并创建远程会话远程容器拿到代码库副本后进行探索和规划本地轮询器持续读取远程事件浏览器侧负责审批计划。本地终端承担的是“控制面”它负责接收用户输入、显示任务状态、保存远程会话地址、启动或停止轮询、在需要时把计划接回来。CCR 远程容器承担的是“执行面”它持有代码库副本、只读探索项目、可选启动多个子代理并行分析最后通过退出计划动作提交方案。这种架构非常像云原生系统客户端不再直接承受全部计算而是把长任务交给远程工作负载本地用任务 Pill、状态轮询和审批结果来管理生命周期。三、触发入口自然关键词让用户少记命令Ultraplan 的入口设计很聪明用户不一定要记住显式命令只要在自然语言任务里写出 ultraplan就可以触发远程规划。比如用户描述一个复杂重构需求只要带上这个关键词本地输入框会给出高亮和提示让用户知道这次会进入远程规划流程。但关键词触发也有风险如果某个文件名、路径、参数、引用文本里出现同样的词就不应该误触发。因此系统需要做上下文过滤识别它到底是“意图触发”还是只是普通文本。这个设计值得借鉴AI 产品的高级能力不能只藏在命令里也不能随便误触发。好的入口应该做到三件事用户表达自然、系统反馈明确、误触发边界清晰。四、启动链路不是发请求而是一次会话迁移当用户确认启动后系统会进入一条严谨的启动链路。第一步是资格检查是否完成 OAuth 登录、订阅级别是否支持远程 Agent、功能开关是否对该账号开放。第二步是构造远程规划提示把用户任务、可能存在的种子计划、会话标识组合起来。第三步是打包代码库把远程端需要的上下文上传到 CCR 容器。随后系统会创建远程会话把会话 URL 写入本地状态并注册一个远程任务。完成这些之后本地不会傻等远程返回而是启动一个后台轮询器。用户马上拿到反馈可以继续做别的事情。这就是远程规划和普通 API 调用的区别普通调用追求“一问一答”远程规划追求“创建一个可持续管理的远程工作流”。五、状态机让复杂生命周期变得可控Ultraplan 的生命周期可以拆成几个关键状态空闲、启动中、运行中、需要用户输入、计划就绪、远程执行、本地接管、终止。每个状态都不是为了好看而是为了让 UI、轮询、错误处理和用户操作有统一依据。比如远程还在探索时本地任务 Pill 显示运行中远程进入空闲但还没提交计划时提示可能需要用户到浏览器补充信息远程已经提交计划时本地就能显示计划就绪如果用户选择把计划传回本地本地要保存计划内容和远程会话信息等待用户决定下一步。状态机的好处是再复杂的远程异步流程也不会变成一堆散乱的 if 判断。所有分支都围绕有限状态变化展开异常路径也能收口。六、轮询与阶段检测远程进度如何回到本地远程容器在工作时会不断产生事件模型输出、工具调用结果、审批状态、终止信号等。本地终端不能一直阻塞等待所以采用后台轮询隔一段时间读取远程事件再把事件流转成三个用户能理解的阶段。第一种阶段是 running说明远程仍在探索和分析。第二种是 needs input说明远程可能空闲或等待用户操作。第三种是 plan ready说明远程已经提交计划等待审批。这里的重点不是轮询本身而是事件扫描器。扫描器要从大量远程事件里识别计划是否待审批、用户是否批准、是否选择传回本地、是否拒绝并给出反馈、会话是否异常终止。只有把这些信号抽象稳定本地 UI 才能可靠展示。七、规划策略轻量单代理与多代理探索远程规划并不只有一种策略。简单任务可以用轻量规划一个远程 Agent 直接读目录、搜文件、理解代码结构然后给出计划。复杂任务则可以启用多代理探索不同代理分别负责架构理解、影响面扫描、风险识别、批判审查最后由主规划 Agent 合成最终方案。这和现实团队做技术方案很像。一个人看代码很快但容易漏视角多人并行探索更全面但也会带来成本和协调复杂度。因此真正的工程设计不是永远多代理而是根据任务复杂度选择策略。多代理规划的价值在于把“一个大脑硬想”变成“多个专家分工再汇总”。尤其面对跨模块重构、历史包袱较重的项目、隐含依赖很多的系统多视角探索往往能减少计划盲区。八、GrowthBook 驱动的变体能力可以灰度不必重新发版Ultraplan 里的规划策略、模型选择、超时时间等可以通过功能开关远程配置。这意味着团队可以把不同提示词变体投放给不同用户或不同场景观察成功率、耗时、拒绝次数、计划质量再决定是否扩大范围。这种设计很重要。很多 AI 功能的问题并不是“能不能上线”而是上线后是否稳定、是否省成本、是否真的减少用户工作量。如果所有策略都写死在客户端每次实验都要发版迭代会很慢。功能开关把模型策略、提示策略、超时策略变成可以运营的配置让 AI Agent 从“手工调参”走向“数据驱动迭代”。九、计划传送协议远程做好计划本地也能接管一个非常实用的设计是计划传送。远程端生成计划后用户可以在浏览器里审批。如果批准远程继续执行并产出 PR如果拒绝并给反馈远程根据反馈修改计划如果用户想把计划拿回本地则通过一个明确的传送标记告诉远程端停止实现本地终端接收计划并继续。这个机制体现了一个非常好的产品原则远程能力不能剥夺本地控制权。用户把规划交给远程不代表必须把执行也交给远程。尤其在企业项目里有些改动涉及本地环境、私有依赖、内部调试工具、特殊权限传回本地执行更合适。从工程角度看传送协议就是一种轻量跨端通信浏览器把用户选择变成明确标记远程模型识别后停止执行本地扫描器提取计划并进入待选择状态。十、错误处理远程任务必须能失败得体面远程规划最怕的不是失败而是失败后留下一堆半死不活的状态本地以为还在跑远程其实已经挂了浏览器里有会话本地已经没入口用户取消了资源还在占用。因此系统需要错误处理矩阵。启动阶段可能因为认证、订阅、功能开关、代码打包失败而中断运行阶段可能因为网络错误、远程终止、超时而失败审批阶段可能因为等待太久或用户取消而结束。每条路径都要清理本地状态并尽量归档远程会话。这类设计对企业 Agent 平台尤其关键。远程任务越多越需要防止孤儿任务、状态泄漏、资源浪费和不可追踪失败。十一、遥测事件没有数据就没有持续优化Ultraplan 这种能力天然需要遥测。系统要知道关键词是否触发、会话是否成功创建、运行多久、是否等待用户输入、计划是否被批准、拒绝了几次、最终选择远程执行还是本地接管、失败原因是什么。这些数据不是为了“记录热闹”而是为了回答产品和工程问题哪个提示词变体更稳多代理探索是否真的提高通过率30 分钟超时是否合理用户更喜欢远程执行还是本地接管哪些错误最常见没有遥测AI Agent 就是一团黑盒有了遥测它才可以像成熟后端系统一样被观察、被实验、被优化。十二、抽象成通用模式远程卸载模式把 Ultraplan 抽象出来它其实是一种可复用的“远程卸载模式”。本地侧负责轻入口、快速反馈、状态展示、审批和取消远程侧负责重模型、长时间探索、多代理并行和结果产出。中间通过会话创建、状态轮询、计划审批和结果传送连接起来。这个模式不只适合编程。任何长时间 AI 任务都可以借鉴复杂数据分析、自动化测试设计、知识库重构、代码迁移规划、系统排障、合规审查都可以把重活放远端把关键控制点留给人。真正的关键是远程不是为了替代本地而是为了释放本地自动化不是为了跳过用户而是为了让用户只在关键节点决策。十三、企业级 Agent 平台怎么借鉴如果你在企业里做 AI Agent 平台可以把这套思路拆成五层。第一层是权限层谁能启动远程任务哪些项目能上传哪些功能开关开放。第二层是上下文层怎么打包代码、文档、历史计划和依赖信息。第三层是规划层轻量规划、多代理探索、批判审查如何选择。第四层是控制层状态机、轮询、取消、超时、失败归档、审计记录。第五层是交付层远程执行、本地接管、生成 PR、通知审批、回写结果。这五层一旦建立起来AI Agent 就不再是一个聊天窗口而是一个可以被管理、被审计、被灰度、被扩展的工程系统。十四、最后总结Ultraplan 的价值不只是远程跑得更久Ultraplan 真正值得关注的地方不是它把计划放到远程执行而是它把“计划”这件事做成了完整工程能力入口可感知、启动可校验、远程可运行、状态可轮询、审批可分支、失败可归档、策略可实验、结果可迁移。这说明 AI 编程工具正在从“单轮问答”走向“异步任务系统”。未来的 AI Agent 不只是回答问题而是会像一个分布式工作流平台能派生任务、并行探索、远程执行、等待审批、失败恢复、生成交付物。一句话概括Ultraplan 不是一个简单功能而是 AI Agent 从本地助手迈向远程工作系统的重要样板。十五、给技术人的落地清单照着这 10 点设计远程 Agent1. 入口要自然既支持明确命令也支持自然语言触发但必须做好误触发过滤。2. 资格要前置身份、订阅、项目权限、功能开关都应在启动前检查。3. 上下文要可打包远程端要拿到足够信息但不能无限上传。4. 规划要分策略轻任务用单代理复杂任务才启用多代理探索。5. 状态要可视化用户不需要看日志也能知道远程在运行、等待还是已就绪。6. 轮询要有限制固定节奏、失败上限、总超时、手动停止都必须明确。7. 审批要保留人控批准、拒绝、反馈、传回本地都应该是标准路径。8. 失败要能归档任何异常都要清理本地状态防止远程会话泄漏。9. 配置要能灰度模型、超时、提示词变体都应支持远程配置和 A/B 实验。10. 数据要能闭环启动率、成功率、拒绝率、耗时、失败原因、执行目标都要可观测。参考资料https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd6fkr