一个抖音遥控器的开发小记
内容提要
作者用Mac mini运行抖音并通过AirPlay投屏到电视，让Codex作为Agent接入Free4Chat房间，自动生成含上一条、播放暂停、下一条三个按钮的手机遥控器App。文章重点探讨Agent运行时、本地能力适配、WebRTC数据通道、权限与生成式UI等设计，强调Agent负责构建、传统程序负责确定性执行。
延伸解读
从简单需求到复杂架构的取舍
作者最初只想用手机控制Mac mini上的抖音，最直接的方案是HTTP Server加三个按钮。但为了验证Agent接入本地能力、临时带入Room供他人使用的流程，最终选择了更复杂的Agent驱动路径。这提醒我们，技术选型应服务于真实目标：如果只是实现遥控器，简单方案更合理；如果意在探索Agent协作与能力复用，复杂架构才有意义。
Agent构建与运行时执行的分离
文章强调Agent负责构建阶段：生成Adapter、注册Capability、生成Task App。而运行时热路径完全由传统程序处理，点击按钮触发确定性RPC，不再调用LLM。这种分离避免了每次操作都引入模型延迟、成本和不确定性，尤其适合高频、可验证的交互。对于需要快速响应的控制类应用，让模型退出运行时是更务实的设计。
生成式UI的安全边界
Agent生成的Task App并非直接执行任意JavaScript，而是运行在受限的App Host中，只能访问有限的共享状态和已授权的Capability API。对于会产生真实副作用的操作，还需遵循Human Interaction的安全边界。这解决了“敢不敢运行Agent生成界面”的问题。如果未来涉及开门、打印、移动机器人等操作，这种沙箱和授权机制将变得至关重要。
Room作为临时信任边界
Capability和Adapter始终留在本地Participant，Room只负责在临时协作空间内建立Human、Task与Agent之间的授权关系。Task结束或Room消失后，关系即终止。这种模型避免了将本地能力暴露为永久公网API，也防止Credential向中心仓库集中。对于接入内网设备、打印机或智能家居等敏感场景，这种临时信任边界比中央集成平台更安全、更灵活。
Q&A
抖音遥控器是怎么实现控制Mac mini上的抖音的？
手机上的Generated Task App通过受限的Host API发起Capability Invoke，经可靠的WebRTC DataChannel发送到Mac mini上的Agent Participant，Runtime根据Capability Projection找到douyin_remote适配器，适配器将语义动作转换为macOS本地键盘事件，从而控制抖音切换视频。
为什么按下遥控器按钮不需要再调用一次LLM？
因为设计上将Agent和运行时分离：Build Time由Codex负责构建适配器和生成UI，Run Time则是确定性的热路径，每次点击只是普通的确定性RPC，不经过模型推理，避免了延迟、成本和不确定性。
Free4Chat中的Room在遥控器场景里扮演什么角色？
Room是一个临时的信任边界，负责协调Human、Agent、Task和Capability之间的授权关系，管理Presence、Task生命周期、权限和App元数据等控制面状态，但真正的本地能力调用走Participant Data Plane，不经过Room Durable Object中转。
Agent生成的App为什么可以安全运行？
因为Task App运行在受限的Host Contract中，通过Sandboxed App Surface和Room App Host暴露有限的共享状态与Capability API，不能直接访问Room内部对象、Agent Credential或本机Runtime，且产生副作用的操作需遵循Human Interaction安全边界。
为什么说Runtime knows capabilities, not integrations？
因为Runtime只通过通用Capability RPC知道有哪些语义能力（如douyin_remote的previous、play_pause、next），而不需要理解底层是Accessibility、AppleScript还是其他协议；具体与厂商、设备、操作系统打交道的部分由外部Adapter负责。
这个项目涉及了哪些Agent协议问题空间？
涉及ACP（Host如何控制Agent的Session、权限、取消等）、MCP（Agent如何发现和使用外部工具）、A2A（多个Agent之间的协作与任务交接）以及A2UI（Agent如何将结果变成Human可操作的界面），Free4Chat在真实多人实时Room中将这些边界问题自然串联起来。
为什么最后又绕回了Accessibility？
因为Agent没有手，对于没有API的桌面软件，它需要知道界面上有什么、如何触发动作，而Accessibility Tree、Keyboard Event、UI Automation恰好提供了机器理解GUI的现成入口，这些原本为无障碍设计的能力意外地适用于Agent操作桌面应用。
这个遥控器方案可以复用到其他场景吗？
可以。复用的是整条路径：Local Integration → Semantic Capability → Participant Runtime → Temporary Room → Agent-generated Human Interface。例如B站可以定义bilibili_remote能力，打印机可以定义printer_status能力，未来ESP32等设备也可由旁边的Participant接入。
