mcpField
A
archon-cli

archon-cli

github.com/coleam00Agent 工作流23.8k48 次安装今天更新
代码仓库

关于 archon-cli

通过 Archon 命令行运行多步骤 AI 工作流的技能,面向项目团队。它指导如何依据明确的任务说明启动运行、监控决策、管理运行状态并检查产物。

主要功能

  1. 01查找工作流说明
  2. 02以分离模式启动工作流
  3. 03通过单一流监控运行
  4. 04回应工作流决策请求
  5. 05检查结果和产物

适用场景

  1. 01针对项目问题运行工作流
  2. 02监控多个工作流运行
  3. 03调查卡住或失败的运行
  4. 04汇报前审阅工作流产出

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/coleam00/archon --skill archon-cli

安装后在 Claude Code 中输入/archon-cli确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

authoring/
authoring-workflows.md
node-reference.md
prompting-mistakes.md
variables.md
operate/
managing-runs.md
queues.md
running.md
troubleshooting.md
setup/
setup-and-config.md

详细介绍

Archon CLI

Archon 通过 archon CLI 运行多步骤 AI 工作流。Git 项目默认在隔离的工作树中运行;已注册的文件夹项目则在原位置运行。你负责监督这些运行:编写简报、启动运行、查看一个事件流、回答发给你的决策问题,并阅读每次运行留下的内容。

按意图查阅:

用户想要……阅读
在实际工作中运行工作流operate/running.md
检查、回答、取消或恢复运行operate/managing-runs.md
使用 SDLC 包的队列operate/queues.md
查明运行失败或卡住的原因operate/troubleshooting.md
设置 Archon 或更改配置setup/setup-and-config.md
编写或更改工作流authoring/authoring-workflows.md(然后阅读同一文件夹中的 node-reference.md 和 variables.md)
改进节点提示词或运行消息authoring/prompting-mistakes.md
  • 意图明确时(例如“为 X 构建工作流”“在问题 #42 上运行 archon-ship”),直接查阅参考文档。不要提问。
  • 意图不明确时,询问用户想做上述哪一项。
  • 如果 archon doctor 在某台机器上运行失败,请从 setup/setup-and-config.md 开始。

操作流程

  1. 发现。 archon workflow list --json 会提供简洁的描述。对于每个可能的候选项,使用 archon workflow list <name> --full 阅读完整描述。根据完整描述进行选择,切勿凭记忆中的名称选择。

  2. 检查简报。 运行所读取的消息、问题正文或文档,就是衡量运行效果的依据。它必须说明问题、解决问题的价值、为何是现在、期望结果、不变量和验收标准。如果缺少任何一项,请指出缺少的内容,提出措辞建议,并在启动前征得用户同意。完整检查方法见 operate/running.md。

  3. 分离启动。 通过消息、使用 --input 传入工作流声明的输入,或两者兼用来传递工作内容:

    archon workflow run <workflow> --branch <branch-name> "<the work>" --detach
    archon workflow run <workflow> --input <name>=<value> --input <name>=<value> --detach
    
  4. 只监听一次。 无论启动多少次运行,都只将一个事件流作为后台任务交给你的运行环境:

    archon workflow attention --watch --json        # this project; add --all for the install
    

    每行都是 JSON。attention 表示运行需要决策,resolved 表示不再需要决策,terminal 表示运行已结束。根据该行采取行动,然后继续读取。

  5. 审慎作答。 阅读事项的问题、建议及其链接的证据。给出理由,并分离作答: archon workflow respond <run-id> <decision> "<reason>" --detach。 operate/managing-runs.md 涵盖所有形式。

  6. 阅读结果。 运行完成并不等于得出结论。archon workflow get <run-id> --json 会提供标准化的 outcome 和 leave_behind.artifactFiles。在告知用户运行的结论前,先阅读报告。

硬性规则

  • 切勿根据过于简略的简报启动。 输入薄弱不会带来薄弱的结果,而是会以全价给出一个自信、完整,却答非所问的答案。
  • 启动和回答时使用 --detach。 分离运行会启动独立会话,并在 shell 关闭后继续运行。前台 respond 或 resume 会在 shell 内继续运行;关闭 shell 就会停止运行。
  • 只用一个监视器,而不是每次运行都用一个。 一个 workflow attention --watch 流会涵盖范围内的所有运行,包括由触发器或其他会话启动的运行。只有一两个运行时,每个运行使用一个 workflow wait <run-id> 没问题;有几十个时,就会争用数据库。
  • 只有确实要结束任务时才停止工作。 archon workflow cancel 会在节点运行中途停止运行,并丢失该节点的提供方会话和未保存的工作。如果你只是想停止启动更多运行,应让运行到达下一个暂停点或结束。当某一轮卡在永远无法完成的工具或后台命令上时,archon workflow end-turn <run-id> 会结束该轮并保留运行(operate/managing-runs.md,“卡住的一轮”)。
  • 只合并审核过的内容。 手动合并拉取请求时,将合并固定到已审核的头提交(gh pr merge <n> --match-head-commit <sha>),先阅读尚未解决的审核讨论,然后同步你的检出内容。
  • 优先以 Agent 为核心进行编写。 在你编写的工作流中,由带类型化输出的 Agent 节点做判断,脚本读取事实并在边界处执行操作,而 YAML 只负责连接它们。authoring/authoring-workflows.md(“以 Agent 为核心”)包含规则和示例。

注意事项

  • 当前目录决定发现、启动和项目列表所针对的项目。workflow status、workflow runs 和 workflow attention 默认针对该项目;添加 --all 可查看整个安装范围。对于 Git 项目,应从仓库根目录运行。使用 workflow run --folder 注册非 Git 文件夹。完整运行 ID 可在任何目录中使用。
  • Attention 项是已暂停的运行。卡在停滞工具调用上的运行并不属于此类:workflow wait <run-id> 和 workflow status 会显示它。
  • 如果未注册的项目产生了整个安装范围的结果,workflow status 和 workflow runs 会在 JSON 中设置 scopeFallback: true。
  • 只要需要解析输出,就优先使用 --json。
  • archon --help 是权威依据。如果此技能指定的标志被拒绝,应以 CLI 的帮助信息为准,并告知用户存在偏差。

评论

支持 Markdown