OpenHuman hosting 领域解析让 Agent 通过九个hosting_*工具把工作区部署到真实托管平台【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 的src/openhuman/hosting模块是其托管领域hosting domain它负责把工作区workspace中的一个目录真正放上互联网是 OpenHuman 与统一托管 APItinyhosts之间的接缝。本文以 hosting/README.md 为主体结合 mod.rs、tools.rs 与 config/schema/hosting.rs 等源码系统讲解[hosting]配置、凭据解析、九个 Agent 工具的参数契约、双闸门feature 闸门 凭据闸门、回滚语义以及绝不读密钥、绝不越界部署两条安全底线读完即可理解如何为 OpenHuman 接入 Vercel 托管并让 Agent 自主完成部署与回滚。领域定位什么归 OpenHuman什么归 TinyHosts该模块的模块级文档mod.rs把分工讲得很明确TinyHosts 拥有关于托管提供商的一切Vercel 的端点、上传后构建upload-then-build的部署协议、市场数据库marketplace database如何被创建并注入连接、一次 launch 的执行顺序。这一切在 crate 内是提供商无关provider-independent的并且是针对提供商 REST API 的 mock 进行测试的。本模块拥有关于OpenHuman 自己的一切凭据从哪里来、Agent 被允许部署哪个目录、结果如何描述回给模型。这个拆分是刻意的——本领域任何代码都不认识readyState这个词README 原话指 Vercel 的部署状态字段tinyhosts也不认识workspace是什么。在 Cargo.toml 中tinyhosts以 vendored path dependency 的形式引入git submodule update --init vendor/tinyhosts后可用只启用vercelprovider且被hostingfeature 独占。领域内关键文件与 README 表格一一对应文件职责mod.rsAccount凭据解析 共享的dyn Host与resolve_in_workspacetools.rs含 tools_part_01.rs、tools_part_02.rs九个 Agent 工具hosting_tests.rs凭据解析、工作区包含关系containment以及每个工具的参数契约测试[hosting]配置四个字段与凭据解析托管领域在配置文件Config中对应[hosting]段由 config/schema/hosting.rs 定义共四个字段字段类型默认值说明enabledboolfalse总开关。为false时无论存在什么凭据都不注册任何托管工具providerstringvercel提供商 slug当前仅有vercelapi_keystring空提供商 API Key。留空表示从环境变量读取走tinyhosts::ProviderKind::credentials_from_env的查找顺序teamstring空团队/组织/账户作用域留空表示个人账户一个典型配置形如[hosting] enabled true provider vercel api_key # 留空则回退到提供商自己的环境变量 team acme源码里值得注意的细节HostingConfig的Debug实现hosting.rs主动脱敏api_key——配置类整体派生了Debug嵌套打印时绝不能把原始凭据渲染出来所以这里覆盖为redacted。has_api_key()判断本段是否配置了非空白 keyteam()对空白做 trim 后返回Optionstrhosting.rs。凭据解析Account::from_configAccount::from_configmod.rs是凭据解析的唯一入口其语义是**未配置不是错误配置错了才是错误**[hosting].enabled false→ 直接返回Ok(None)工具不注册配置了非空api_key→ 用它构造Credentials若配置了team则附加团队作用域未配置 key → 尝试provider.credentials_from_env()环境里也找不到 → 打debug日志后返回Ok(None)同样是不注册而不是报错只有真正的错误配置未知 provider slug、空白 key、客户端构建失败才返回Err且由注册表registry以warn级别记录——这是配置错误与未配置在故障排查上的关键区分点。另外还有一个为 embedder如 OpenCompany 多租户场景准备的Account::connectmod.rs直接把provider、api_key、team、workspace_dir作为字符串/路径传入embedder 无需在自己的依赖图中引用tinyhosts就能触达工具。九个 Agent 工具参数契约与效果所有工具由hosting_tools()一次性注册tools_part_01.rs共享同一个Account。README 的表格列出九个工具及其读写属性工具效果读写hosting_launch_site把工作区目录部署为线上站点可选创建并注入数据库、设置环境变量、绑定域名外部效果写hosting_deployment_status查询一次构建是否完成只读hosting_list_deployments站点最近部署记录新→旧含状态与 target只读hosting_rollback把生产流量指回一个已构建完成的旧部署外部效果写hosting_list_sites账户下已有的站点只读hosting_set_env为已有站点设置环境变量外部效果写hosting_add_domain绑定自定义域名外部效果写hosting_domain_status站点域名是否已通过验证并开始服务只读hosting_analytics最近 N 天流量只读下面结合工具实现逐一展开参数契约均出自 tools_part_01.rs 与 tools_part_02.rs。hosting_launch_site唯一会花钱的入口这是九个工具里最重要的一个把工作区目录变成带数据库的线上站点。其参数 Schema 如下参数必填默认值说明site是—站点在提供商侧的名称如acme-shop重复调用即重新部署path否.工作区根目录要部署的目录相对工作区database否无托管数据库名称省略表示不需要数据库database_kind否postgres枚举postgres/redis/blobenv否无构建前设置的环境变量对象不要放数据库连接串提供商自己会注入domains否无要绑定的自定义域名数组production否false是否部署到生产而非预览 URL实现要点plan()tools_part_01.rs先经resolve_in_workspace解析目录再用Bundle::from_dir打包随后依次拼接LaunchPlan数据库规格、环境变量、域名、生产目标。数据库类型映射中未识别的other字符串会落到DatabaseKind::Other不会静默失败。工具描述明确声明Node 依赖、构建产物和.git永远不会被上传——提供商是从源码构建的。权限级别为PermissionLevel::Write且external_effect() true因此会走审批门approval gate。执行后返回的结构化结果附带describe()渲染的两句模型可读总结tools_part_01.rs站点创建还是已存在、部署 ID 与状态、待轮询的 URL、数据库注入的变量名称、未验证的域名清单。hosting_set_env与hosting_add_domain另两个写工具hosting_set_envtools_part_02.rs参数site必填、env必填对象、secret默认false置为 true 时以只写方式存于提供商、production_only默认false为 true 时仅作用于生产环境。返回值强调环境变量是 write-only 的永远无法通过本组工具读回且构建期变量需要重新部署才生效。hosting_add_domaintools_part_02.rs参数site、domain如shop.example.com。返回值区分两种成功状态——已附加且已验证与已附加但未验证DNS 记录尚未指向提供商需用户在注册商处完成。只读工具族hosting_deployment_statustools_part_01.rs唯一参数deployment_id必填返回部署完整 JSON。hosting_list_deploymentstools_part_01.rs参数site必填、limit默认 20钳制在 1–100。与hosting_list_sites同样做了 limit 钳制注释说明理由模型要全部就给一页而不是一张账单a model that asks for everything gets a page, not a bill。hosting_list_sitestools_part_01.rs参数仅limit默认 20部署前可用来确认站点是否已存在。hosting_domain_statustools_part_02.rshosting_add_domain的读半边回答之前加的域名起来没有。hosting_analyticstools_part_02.rs参数site必填、days默认 7钳制 1–365、breakdown枚举country/request_path/device_type/browser_name/os_name/referrer_hostname/route。非法 breakdown 值会返回明确的错误而不是静默忽略。为什么有hosting_rollback却没有单独的 promote这是 README 专门花一节解释的设计决策Host::promote一鱼两吃——回滚本质就是把生产流量 promote 到一个更旧的部署crate 只建模一次而不是两次工具按 Agent 使用它的原因命名。hosting_rollbacktools_part_01.rs的实现揭示了三个关键语义promote 前先读部署状态。hosting_list_deployments连失败中的、仍在构建的部署也会返回——它们是 Agent 正在阅读的历史——所以 Agent 挑出的 ID 未必能对外服务。把失败的构建 promote 上去会在试图把站点救回来的当口把站点打挂这正是本工具要防止的唯一结局。因此只有deployment.status.is_ready()才允许 promote否则返回明确错误并提示用hosting_list_deployments找一个 ready 的。故意不校验部署属于指定站点。Host::deployment只按 ID 查部署提供商响应可能省略项目名此时回退为空名若拿它和site比较会误拒合法的回滚。这个校验归提供商所有。成功后明确告知变更在提供商的边缘生效什么都没重建——这正是回滚是最快退路的原因。配套测试rolling_back_to_a_deployment_that_never_built_does_not_touch_production与rolling_back_to_a_ready_deployment_promotes_ithosting_tests.rs分别验证了这两条路径。双闸门feature 闸门与凭据闸门README 强调两个闸门而且都重要hostingCargo feature 闸门默认 OFF、产品构建 ON。关闭时整个领域根本不参与编译。见 Cargo.toml 的hosting [dep:tinyhosts]以及 openhuman/mod.rs 的#[cfg(feature hosting)] pub mod hosting;。凭据闸门Account::from_config在[hosting].enabled false或任何地方都找不到 key 时返回Ok(None)随后tools::ops什么都不注册。设计哲学是一个存在却干不了活的工具比一个不存在的工具更糟——因为模型会反复重试它。而配置错误未知 provider slug、空白配置 key则是报错而非静默跳过由注册表以warn级别记录见 hosting.rs 附近的错误语义与 mod.rs 的 debug 日志路径。测试hosting_off_yields_no_account、a_configured_key_yields_an_account、an_unknown_provider_is_an_error_rather_than_a_silent_skiphosting_tests.rs精确锁定了这三条行为。两条安全底线不读密钥、不越界部署README 用这个领域不会做的两件事来收尾绝不读 secret。托管数据库的连接串由提供商注入到站点环境里本进程只学到变量的名称而永远学不到值——这正是hosting_launch_site报告DATABASE_URL而不是某个 URL 的原因describe()只拼接launch.database_env_keys的变量名清单。绝不部署用户没点名的东西。resolve_in_workspacemod.rs是领域内唯一决定什么可以离开这台机器的地方拒绝绝对路径、拒绝..逃逸、拒绝非目录而一次部署会把给定目录下的每一个字节都上传给第三方。实现上通过canonicalize()后校验canonical.starts_with(root)完成包含关系判断。对应测试覆盖了包含关系的全部四个面目录内解析成功、空路径视为工作区根、工作区外路径被拒、文件不是可部署目录hosting_tests.rs 中a_directory_inside_the_workspace_resolves等用例。事件与审批路由该领域不产生任何事件没有bus.rs没有EventHandler。审批路由完全依赖Tool::external_effect钩子——即hosting_launch_site、hosting_rollback、hosting_set_env、hosting_add_domain四个写工具返回true由 Agent harness 读取该标志决定是否拦截审批其余五个只读工具返回false。测试only_the_tools_that_change_the_world_carry_an_external_effecthosting_tests.rs专门锁定这一定义另有every_tool_schema_is_an_object_naming_its_required_arguments守护九份参数 Schema 的完备性。小结一个可独立验证的领域边界从 README 到源码src/openhuman/hosting展示了一套清晰的领域设计样板提供商细节全部下沉到tinyhostscrateOpenHuman 侧只保留凭据解析—路径约束—工具契约—结果描述四件事。接入方只需配好[hosting]段或调用Account::connect打开hostingfeatureAgent 即可通过九个hosting_*工具完成从部署一个带数据库的站点到发现线上故障并回滚到历史好版本的完整闭环而凭据、审批与工作区边界三条安全线由领域自身兜底。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenHuman hosting 领域解析：让 Agent 通过九个 `hosting_*` 工具把工作区部署到真实托管平台
OpenHuman hosting 领域解析让 Agent 通过九个hosting_*工具把工作区部署到真实托管平台【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 的src/openhuman/hosting模块是其托管领域hosting domain它负责把工作区workspace中的一个目录真正放上互联网是 OpenHuman 与统一托管 APItinyhosts之间的接缝。本文以 hosting/README.md 为主体结合 mod.rs、tools.rs 与 config/schema/hosting.rs 等源码系统讲解[hosting]配置、凭据解析、九个 Agent 工具的参数契约、双闸门feature 闸门 凭据闸门、回滚语义以及绝不读密钥、绝不越界部署两条安全底线读完即可理解如何为 OpenHuman 接入 Vercel 托管并让 Agent 自主完成部署与回滚。领域定位什么归 OpenHuman什么归 TinyHosts该模块的模块级文档mod.rs把分工讲得很明确TinyHosts 拥有关于托管提供商的一切Vercel 的端点、上传后构建upload-then-build的部署协议、市场数据库marketplace database如何被创建并注入连接、一次 launch 的执行顺序。这一切在 crate 内是提供商无关provider-independent的并且是针对提供商 REST API 的 mock 进行测试的。本模块拥有关于OpenHuman 自己的一切凭据从哪里来、Agent 被允许部署哪个目录、结果如何描述回给模型。这个拆分是刻意的——本领域任何代码都不认识readyState这个词README 原话指 Vercel 的部署状态字段tinyhosts也不认识workspace是什么。在 Cargo.toml 中tinyhosts以 vendored path dependency 的形式引入git submodule update --init vendor/tinyhosts后可用只启用vercelprovider且被hostingfeature 独占。领域内关键文件与 README 表格一一对应文件职责mod.rsAccount凭据解析 共享的dyn Host与resolve_in_workspacetools.rs含 tools_part_01.rs、tools_part_02.rs九个 Agent 工具hosting_tests.rs凭据解析、工作区包含关系containment以及每个工具的参数契约测试[hosting]配置四个字段与凭据解析托管领域在配置文件Config中对应[hosting]段由 config/schema/hosting.rs 定义共四个字段字段类型默认值说明enabledboolfalse总开关。为false时无论存在什么凭据都不注册任何托管工具providerstringvercel提供商 slug当前仅有vercelapi_keystring空提供商 API Key。留空表示从环境变量读取走tinyhosts::ProviderKind::credentials_from_env的查找顺序teamstring空团队/组织/账户作用域留空表示个人账户一个典型配置形如[hosting] enabled true provider vercel api_key # 留空则回退到提供商自己的环境变量 team acme源码里值得注意的细节HostingConfig的Debug实现hosting.rs主动脱敏api_key——配置类整体派生了Debug嵌套打印时绝不能把原始凭据渲染出来所以这里覆盖为redacted。has_api_key()判断本段是否配置了非空白 keyteam()对空白做 trim 后返回Optionstrhosting.rs。凭据解析Account::from_configAccount::from_configmod.rs是凭据解析的唯一入口其语义是**未配置不是错误配置错了才是错误**[hosting].enabled false→ 直接返回Ok(None)工具不注册配置了非空api_key→ 用它构造Credentials若配置了team则附加团队作用域未配置 key → 尝试provider.credentials_from_env()环境里也找不到 → 打debug日志后返回Ok(None)同样是不注册而不是报错只有真正的错误配置未知 provider slug、空白 key、客户端构建失败才返回Err且由注册表registry以warn级别记录——这是配置错误与未配置在故障排查上的关键区分点。另外还有一个为 embedder如 OpenCompany 多租户场景准备的Account::connectmod.rs直接把provider、api_key、team、workspace_dir作为字符串/路径传入embedder 无需在自己的依赖图中引用tinyhosts就能触达工具。九个 Agent 工具参数契约与效果所有工具由hosting_tools()一次性注册tools_part_01.rs共享同一个Account。README 的表格列出九个工具及其读写属性工具效果读写hosting_launch_site把工作区目录部署为线上站点可选创建并注入数据库、设置环境变量、绑定域名外部效果写hosting_deployment_status查询一次构建是否完成只读hosting_list_deployments站点最近部署记录新→旧含状态与 target只读hosting_rollback把生产流量指回一个已构建完成的旧部署外部效果写hosting_list_sites账户下已有的站点只读hosting_set_env为已有站点设置环境变量外部效果写hosting_add_domain绑定自定义域名外部效果写hosting_domain_status站点域名是否已通过验证并开始服务只读hosting_analytics最近 N 天流量只读下面结合工具实现逐一展开参数契约均出自 tools_part_01.rs 与 tools_part_02.rs。hosting_launch_site唯一会花钱的入口这是九个工具里最重要的一个把工作区目录变成带数据库的线上站点。其参数 Schema 如下参数必填默认值说明site是—站点在提供商侧的名称如acme-shop重复调用即重新部署path否.工作区根目录要部署的目录相对工作区database否无托管数据库名称省略表示不需要数据库database_kind否postgres枚举postgres/redis/blobenv否无构建前设置的环境变量对象不要放数据库连接串提供商自己会注入domains否无要绑定的自定义域名数组production否false是否部署到生产而非预览 URL实现要点plan()tools_part_01.rs先经resolve_in_workspace解析目录再用Bundle::from_dir打包随后依次拼接LaunchPlan数据库规格、环境变量、域名、生产目标。数据库类型映射中未识别的other字符串会落到DatabaseKind::Other不会静默失败。工具描述明确声明Node 依赖、构建产物和.git永远不会被上传——提供商是从源码构建的。权限级别为PermissionLevel::Write且external_effect() true因此会走审批门approval gate。执行后返回的结构化结果附带describe()渲染的两句模型可读总结tools_part_01.rs站点创建还是已存在、部署 ID 与状态、待轮询的 URL、数据库注入的变量名称、未验证的域名清单。hosting_set_env与hosting_add_domain另两个写工具hosting_set_envtools_part_02.rs参数site必填、env必填对象、secret默认false置为 true 时以只写方式存于提供商、production_only默认false为 true 时仅作用于生产环境。返回值强调环境变量是 write-only 的永远无法通过本组工具读回且构建期变量需要重新部署才生效。hosting_add_domaintools_part_02.rs参数site、domain如shop.example.com。返回值区分两种成功状态——已附加且已验证与已附加但未验证DNS 记录尚未指向提供商需用户在注册商处完成。只读工具族hosting_deployment_statustools_part_01.rs唯一参数deployment_id必填返回部署完整 JSON。hosting_list_deploymentstools_part_01.rs参数site必填、limit默认 20钳制在 1–100。与hosting_list_sites同样做了 limit 钳制注释说明理由模型要全部就给一页而不是一张账单a model that asks for everything gets a page, not a bill。hosting_list_sitestools_part_01.rs参数仅limit默认 20部署前可用来确认站点是否已存在。hosting_domain_statustools_part_02.rshosting_add_domain的读半边回答之前加的域名起来没有。hosting_analyticstools_part_02.rs参数site必填、days默认 7钳制 1–365、breakdown枚举country/request_path/device_type/browser_name/os_name/referrer_hostname/route。非法 breakdown 值会返回明确的错误而不是静默忽略。为什么有hosting_rollback却没有单独的 promote这是 README 专门花一节解释的设计决策Host::promote一鱼两吃——回滚本质就是把生产流量 promote 到一个更旧的部署crate 只建模一次而不是两次工具按 Agent 使用它的原因命名。hosting_rollbacktools_part_01.rs的实现揭示了三个关键语义promote 前先读部署状态。hosting_list_deployments连失败中的、仍在构建的部署也会返回——它们是 Agent 正在阅读的历史——所以 Agent 挑出的 ID 未必能对外服务。把失败的构建 promote 上去会在试图把站点救回来的当口把站点打挂这正是本工具要防止的唯一结局。因此只有deployment.status.is_ready()才允许 promote否则返回明确错误并提示用hosting_list_deployments找一个 ready 的。故意不校验部署属于指定站点。Host::deployment只按 ID 查部署提供商响应可能省略项目名此时回退为空名若拿它和site比较会误拒合法的回滚。这个校验归提供商所有。成功后明确告知变更在提供商的边缘生效什么都没重建——这正是回滚是最快退路的原因。配套测试rolling_back_to_a_deployment_that_never_built_does_not_touch_production与rolling_back_to_a_ready_deployment_promotes_ithosting_tests.rs分别验证了这两条路径。双闸门feature 闸门与凭据闸门README 强调两个闸门而且都重要hostingCargo feature 闸门默认 OFF、产品构建 ON。关闭时整个领域根本不参与编译。见 Cargo.toml 的hosting [dep:tinyhosts]以及 openhuman/mod.rs 的#[cfg(feature hosting)] pub mod hosting;。凭据闸门Account::from_config在[hosting].enabled false或任何地方都找不到 key 时返回Ok(None)随后tools::ops什么都不注册。设计哲学是一个存在却干不了活的工具比一个不存在的工具更糟——因为模型会反复重试它。而配置错误未知 provider slug、空白配置 key则是报错而非静默跳过由注册表以warn级别记录见 hosting.rs 附近的错误语义与 mod.rs 的 debug 日志路径。测试hosting_off_yields_no_account、a_configured_key_yields_an_account、an_unknown_provider_is_an_error_rather_than_a_silent_skiphosting_tests.rs精确锁定了这三条行为。两条安全底线不读密钥、不越界部署README 用这个领域不会做的两件事来收尾绝不读 secret。托管数据库的连接串由提供商注入到站点环境里本进程只学到变量的名称而永远学不到值——这正是hosting_launch_site报告DATABASE_URL而不是某个 URL 的原因describe()只拼接launch.database_env_keys的变量名清单。绝不部署用户没点名的东西。resolve_in_workspacemod.rs是领域内唯一决定什么可以离开这台机器的地方拒绝绝对路径、拒绝..逃逸、拒绝非目录而一次部署会把给定目录下的每一个字节都上传给第三方。实现上通过canonicalize()后校验canonical.starts_with(root)完成包含关系判断。对应测试覆盖了包含关系的全部四个面目录内解析成功、空路径视为工作区根、工作区外路径被拒、文件不是可部署目录hosting_tests.rs 中a_directory_inside_the_workspace_resolves等用例。事件与审批路由该领域不产生任何事件没有bus.rs没有EventHandler。审批路由完全依赖Tool::external_effect钩子——即hosting_launch_site、hosting_rollback、hosting_set_env、hosting_add_domain四个写工具返回true由 Agent harness 读取该标志决定是否拦截审批其余五个只读工具返回false。测试only_the_tools_that_change_the_world_carry_an_external_effecthosting_tests.rs专门锁定这一定义另有every_tool_schema_is_an_object_naming_its_required_arguments守护九份参数 Schema 的完备性。小结一个可独立验证的领域边界从 README 到源码src/openhuman/hosting展示了一套清晰的领域设计样板提供商细节全部下沉到tinyhostscrateOpenHuman 侧只保留凭据解析—路径约束—工具契约—结果描述四件事。接入方只需配好[hosting]段或调用Account::connect打开hostingfeatureAgent 即可通过九个hosting_*工具完成从部署一个带数据库的站点到发现线上故障并回滚到历史好版本的完整闭环而凭据、审批与工作区边界三条安全线由领域自身兜底。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考