Sortie
将问题跟踪器中的工单转化为并行、可恢复的编码代理会话。
按维度查看评分与理由
CI 工作流将默认权限限制为只读、禁用检出凭据持久化并以提交哈希固定第三方 Actions；安全政策还陈述了路径约束、工作区名称清理、执行目录校验、环境变量密钥间接引用和不记录密钥。README 说明无遥测，并明确归因于 OpenAI Symphony，许可证和仓库来源也清楚，因此来源归因可获满分。扣分在于：提供的实现代码不能验证安全不变量；编排器会运行具有代码和网络副作用的代理，却未展示最小化代理权限、逐项确认或审批门；反馈可写回跟踪器，但外部写入范围和确认机制不清；运行历史能够保留状态，但没有证明可撤销代理提交、跟踪器写入或其他外部效果。依赖和 Actions 有明确版本、自动更新流程及漏洞报告政策，但未提供漏洞扫描、SBOM 或所列版本无已知漏洞的证据。
README、SECURITY、go.mod 和 CI 对 Go 单二进制、跨平台范围、SQLite 持久化及安全维护模式的描述相互一致，未发现直接矛盾，因此自洽性较强。静态链接和较小的直接依赖集合降低运行时依赖，但安装端点、问题跟踪器、编码代理及可选服务仍是外部可用性条件。材料说明失败运行会自动重试、历史可跨重启保留，并提供安全事件响应流程；扣分是未给出面向用户的具体运行错误格式、重试上限、退避策略、不可恢复错误分类或部分失败处理示例。
目标用户、问题场景、支持的五类跟踪器和六类编码代理都被明确列出，且支持本机或服务器、并行会话以及可热更新的 WORKFLOW.md，受众与场景覆盖充分。安全政策区分 Sortie、第三方代理和部署加固责任，也列出安全边界；但真正的代理能力限制、网络和命令权限仍依赖未提供的配置及架构文件。触发机制被描述为匹配所选问题并依据 WORKFLOW.md 启动，不过没有展示匹配语法、去重、竞态处理或误触发防护。Linux、macOS 和 Windows 均有 CI 覆盖，但部署前提、容器环境和不同跟踪器或代理的兼容性细节不足。
README 的问题、兼容性、安装、工作原理、文档、先前工作和许可证结构清楚；项目命名、WORKFLOW.md、模块路径及安全术语一致。Apache-2.0 全文存在并与元数据一致，因此许可证获满分。安装提供脚本、Homebrew、无外部服务的演示入口和正式入门入口，但管道执行远程脚本未附校验、固定版本或手动安装说明。示例主要是链接和一个测试脚本，未提供完整常见问题集。安全政策详列支持窗口、范围和报告渠道，但一般操作限制仍较少。语义版本和 CHANGELOG 更新路径被陈述，然而 CHANGELOG 内容未包含在证据中。维护渠道、时限和安全邮箱明确，但发布者身份未经企业登记验证，且未展示具体维护者或治理结构。
产出可通过运行历史、进度、成本以及 CI 和评审反馈继续处理，能支持普通工程工作流；但没有展示实际会话报告、补丁交付格式、审阅界面或完成判定样例，因此输出可用性未达全面水平。把多个现有编码代理与跟踪器、隔离工作区、重试和持久化整合为单一编排器，较手工逐项启动具有明确增量价值。单二进制、SQLite 和并行执行降低部署负担，并提供成本跟踪；扣分是未量化计算、令牌、存储、并发上限或维护成本，也没有基准或案例证明收益。
多数主要主张能够对应 README、SECURITY、go.mod 或 CI 中的具体陈述，例如依赖版本、跨平台测试、权限设置、许可和支持政策。扣分是若干关键安全和功能主张只在文档中声明，相关实现、架构章节、CHANGELOG 和完整测试未随材料提供，无法逐项追踪。不同文件对依赖、平台、凭据管理和测试策略形成一定交叉印证，但没有独立来源或完整代码证据。材料通常将产品主张、安全政策和测试配置分开表达，不过营销性效率主张及“从不记录密钥”“无遥测”等事实没有在所给源码中明确标注为已实现证据还是设计要求。
- 编排器会启动能够修改代码、调用网络并可能写回问题跟踪器的第三方代理；部署前应单独限制每个代理的文件系统、命令、网络和令牌权限。
- 不要仅凭 SECURITY.md 的陈述认定路径隔离、密钥脱敏或无遥测已经得到实现验证；本次材料未包含对应实现代码。
- 安装命令通过管道直接执行远程脚本；在受控环境中应先下载、审查并校验固定版本的安装程序。
- 自动重试和并行运行可能重复或放大外部副作用；在确认去重、重试上限、审批门和恢复流程之前，不宜用于不可逆任务。
- 发布者身份未知但不因此被视为可疑；组织应通过自己的供应链和维护者尽调建立信任。
这个 Agent 能做什么，适合哪些场景？
Sortie 是一个以 Go 编写、可自行托管的编码代理编排器，用于把问题跟踪器中的待办事项交给多个编码代理并行处理。它通过一个 WORKFLOW.md 文件定义要选择的问题、使用的代理以及交给代理的指令。每个任务在独立工作区中运行，执行历史与成本数据会持久保存，并且进程重启后仍可恢复。系统能够自动重试失败任务，还可利用 CI 失败和评审意见继续驱动代理。它以单个二进制文件部署，使用 SQLite 持久化，无需另行部署数据库或任务队列，并声明自身不发送遥测数据。
Sortie 从 GitHub Issues、GitLab Issues、Gitea Issues、Linear 或 Jira 中挑选符合 WORKFLOW.md 条件的问题。该文件同时指定 Claude Code、Copilot、OpenCode、Codex、Kiro 或 Gemini 等编码代理以及运行指令。编排器为每个问题创建隔离工作区并并行启动代理，保存运行历史、进度和成本信息；失败的运行会自动重试。启用相关反馈后，CI 失败和代码评审意见可以再次传给代理。工作流配置可在不重启 Sortie 的情况下更新，持久状态由 SQLite 保存。
- 维护多个代码仓库的工程团队，希望把 GitHub、GitLab 或 Gitea 中筛选出的缺陷并行交给现有编码代理处理。
- 使用 Jira 或 Linear 管理迭代的团队，需要将工单自动转换为彼此隔离、可重试的编码会话。
- DevOps 团队需要让 CI 失败信息和评审意见返回给编码代理，以便继续修正任务。
- 同时采用 Claude Code、Codex、Copilot、OpenCode、Kiro 或 Gemini 的团队，希望由同一个自托管编排器调度这些工具。
- 不想额外维护数据库和消息队列的小型团队，希望用单个二进制文件运行代理队列并保留历史与成本记录。
这个 Agent 有哪些优点和局限？
- 原生支持五类问题跟踪器和六种编码代理，避免把编排流程绑定到单一厂商。
- 每个任务使用独立工作区，并支持并行执行和失败自动重试。
- 运行历史可跨重启保存，同时能够跟踪任务进度与成本。
- 可以把 CI 失败和评审意见重新交给代理，形成后续修正循环。
- 单二进制加 SQLite 的部署边界明确，不要求独立数据库或任务队列，且声明不发送遥测。
- 采用前仍需为每个问题跟踪器和编码代理准备连接配置、凭据及相应权限，而所给材料未列出具体要求。
- 完整自动化依赖外部问题跟踪器、编码代理以及可选的 CI 和评审反馈链路，这些服务的故障或限额会影响执行。
- 所给材料没有展示 WORKFLOW.md 的结构或实际启动命令，无法据此评估首次配置的复杂度。
- 虽然架构称支持可插拔适配器，但所给材料没有提供开发自定义适配器的接口细节或兼容性保证。
如何安装或部署这个 Agent？
在支持 shell 的本机或服务器上运行：
curl -sSL https://get.sortie-ai.com/install.sh | shmacOS 也可使用 Homebrew：
brew install --cask sortie-ai/tap/sortie安装脚本需要网络访问。所给材料未注明受支持的操作系统版本、安装目录、最低 Go 或系统版本，也未提供校验安装结果的命令。
如何使用这个 Agent？
首先创建一个 WORKFLOW.md，在其中选择要处理的问题、要运行的编码代理以及任务指令；随后让 Sortie 读取匹配的问题并启动会话。若不连接外部服务，可使用文档中的本地演示流程和模拟代理；若连接真实服务，则需配置所选问题跟踪器和编码代理。所给材料没有提供 WORKFLOW.md 的字段示例、启动 Sortie 的具体 CLI 命令、环境变量名称或各服务所需的凭据与权限范围，因此无法仅凭这些材料给出完整且可复制的首次运行命令。
这个 Agent 与同类方案有什么区别？
Sortie 明确说明其架构受到 OpenAI Symphony 启发。相较于 Symphony 的 Elixir 参考实现，Sortie 选择 Go 以简化部署，使用 SQLite 而非内存状态，通过可插拔适配器支持多种问题跟踪器和编码代理，并由编排器管理交接状态转换，而不是只依赖代理主动写回跟踪器。