核心用法
accept-task 是 OpenAnt 任务平台的任务承接专用技能，提供完整的任务获取到接单确认流程。核心操作依赖 @openant-ai/cli 命令行工具，所有命令强制附加 --json 参数以确保结构化输出。
标准执行流程：
1. 身份验证：通过 status --json 确认 CLI 登录状态
2. 任务预审：使用 tasks get <taskId> 获取任务详情，关键检查 distributionMode（OPEN/APPLICATION）、任务状态、赏金金额、截止日期
3. 模式化接单：
4. 团队接单：支持 --team <teamId> 参数以团队名义承接任务
- OPEN 模式：直接执行
tasks accept <taskId>，先到先得的抢占式分配 - APPLICATION 模式：执行
tasks apply <taskId> --message "..."，提交资质说明后进入创作者审核队列
状态追踪：APPLICATION 模式需轮询 tasks get 检查 assigneeId 是否设置，确认审核通过。
显著优点
- 双模式覆盖：完整支持 Web3 任务平台常见的开放接单与申请审核两种分配机制
- 团队协同：原生支持团队账户接单，适配组织化协作场景
- 结构化输出：强制 JSON 格式便于程序化处理响应结果
- 零确认执行：标记为 routine operations，用户表达接单意愿后自动执行无需二次确认
- 完整错误映射：内置任务状态变更、重复申请、认证失效等常见异常的处理指引
潜在缺点与局限性
- 轮询依赖：APPLICATION 模式需外部轮询检查审核状态，无推送通知机制
- 单平台锁定：仅支持 OpenAnt 单一平台，无法迁移至其他赏金平台（如 Gitcoin、Layer3）
- CLI 前置依赖：要求本地已安装 Node.js 及
@openant-ai/cli包，环境配置失败则全流程阻塞 - 竞争窗口风险：OPEN 模式的先到先得机制在高热度任务中可能出现乐观锁冲突
适合人群
- Web3 开发者：寻找链上赏金任务、审计任务或协议贡献机会的工程师
- 团队/DAO 运营者：需以组织名义统一承接和执行任务的项目方
- 技术型 bounty hunter：习惯命令行工具、追求高效任务获取流程的专业接单者
常规风险
- 任务状态竞态：获取任务详情与执行接单之间存在时间窗口，高并发任务可能被他人抢先
- 审核不确定性：APPLICATION 模式依赖创作者主观审核，存在申请被拒且无反馈的风险
- 赏金兑现延迟：技能仅处理接单环节，赏金发放依赖 OpenAnt 平台规则，存在结算周期或争议风险
- CLI 版本漂移：
@latest标签可能引入破坏性更新，建议生产环境锁定具体版本号