最新

嗨，HN——我开发了Clawx，这是一个将代理驱动的任务视为可安装包的实验。 Clawx包是一个包含YAML元数据的Markdown文件。Markdown主体成为代理CLI（如Claude Code、Codex、OpenCode、Gemini或Antigravity）的系统提示。Clawx从注册中心获取包，验证其SHA-256哈希，显示其请求的权限，询问批准，执行该操作，并记录执行过程。 这个想法源于我反复编写相同的操作提示：配置CI、检查代码库、安装并验证工具、搭建项目规范或执行多步骤迁移。Shell脚本是确定性的，但在不同项目中往往比较脆弱。原始提示是灵活的，但容易丢失、静默更改或在缺乏结构的情况下执行。我想探索这两者之间的一个平衡点。 包可以声明参数、依赖关系、所需的环境变量和允许的工具。注册中心可以是Git仓库或小型HTTP服务器。还有一个离线工作区扫描器，可以查看清单和基础设施文件，并推荐相关包。 一个重要的限制是：在使用Claude Code时，工具限制在子进程边界由Clawx强制执行。对于其他提供者，声明的工具目前在批准时显示，但执行取决于该提供者自己的沙箱和权限模型。我不想暗示比实现所提供的更强的安全边界。 你可以在macOS或Linux上通过以下命令安装： ``` curl -fsSL https://raw.githubusercontent.com/debarshibasak/clawx/master/install.sh | sh ``` 然后，假设已安装支持的代理CLI之一： ``` clawx list clawx info gitignore-gen clawx run gitignore-gen clawx history ``` 该项目是用Go语言编写的，目前仍处于早期阶段。我特别希望获得关于代理任务作为“包”是否有用的反馈，信任模型应该是什么样的，以及与脚本、配置管理或特定提供者技能相比，这种抽象在哪些方面存在问题。