OpenFang 定时自主代理 Hands

它解决什么问题

把一个自主代理工作流跑起来一次，只是第一步。真正棘手的是第二步到第 N 步：流程要在固定时间被触发、要有地方看它实际做了什么、要在它触碰敏感操作时拦下来。临时拼出来的脚本会让这些需求各自长成孤岛——调度靠 cron，状态写在本地文件，审计靠翻日志。OpenFang 的出发点是把执行环境本身当成一等公民。它自称是开源的 Agent Operating System，并且明确表示自己不是聊天机器人框架、不是 LLM 的 Python 封装，也不是常见的「多智能体编排器」，而是从零构建的代理操作系统。

核心能力

这个技能把打包好的自主代理工作流交给 OpenFang，由它在计划的时间点触发执行。具体能力包括：

• 计划执行：把工作流注册为可调度的任务，而不是每次手动拉起进程。
• 清单管理：通过 manifest 描述工作流的组成与依赖，执行边界落在配置里，而不是散落在代码里。
• 本地仪表盘：提供本地 dashboard 观察运行状态，不必再外接一套监控体系。
• 报告输出：每次运行都有可追溯的结果记录，方便事后回查失败原因。
• 敏感操作护栏：对高风险动作设置 guardrails，在执行前进行拦截或要求确认。

上手前需要备齐：OpenFang 的 CLI 或二进制、本地 dashboard，以及该工作流依赖的 provider 凭证或集成。

适用边界

OpenFang 用 Rust 实现，上游资料强调其安全模型是 16 discrete 层离散防护，这和常见的「一层包装」思路不同。代价是需要按它的概念模型组织工作流，现有脚本不能直接平替。资料给出的空闲内存占用约 8.8 MB，常驻运行没有压力。

需要注意的几点：

• 工作流必须按 OpenFang 的 manifest 规范打包，零散的 shell 脚本享受不到调度和护栏。
• 护栏只覆盖被识别为敏感的操作，判定依据来自配置，业务里的高风险动作需要自己梳理清楚。
• 凭证与集成按工作流逐个准备，缺失会在运行时暴露。

文档见 https://www.openfang.sh/。