mcpField
A
autonomous-agent-readiness

autonomous-agent-readiness

github.com/petekpAgent 工作流1056 次安装21 周前更新
代码仓库

关于 autonomous-agent-readiness

用于评估代码库是否适合自主 Agent 执行的技能，根据基础设施与工作流检查结果给出分维度评分和改进建议。适合希望减少人工介入、提升执行可重复性的开发团队。

主要功能

  1. 01评估隔离、环境与会话独立性
  2. 02检查自动化、状态与结果验证
  3. 03按维度评分并识别差距
  4. 04提供按优先级排序的改进建议

适用场景

  1. 01评估项目能否支持自主执行
  2. 02为代码库规划自动化改造
  3. 03识别运行环境中的依赖与风险

安装

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

$npx skills add https://github.com/petekp/agent-skills --skill autonomous-agent-readiness

安装后在 Claude Code 中输入/autonomous-agent-readiness确认已加载。

附带文件references/assessment-criteria.mdscripts/discover.py

详细介绍

自主 Agent 就绪度评估

根据经过验证的自主 Agent 执行模式评估代码库，并提供针对性建议。

核心理念

大多数 Agent 故障源于系统设计，而非模型本身。每一步都需要人工审批，或依赖开发者的笔记本电脑保持开机的 Agent，都不具备自主性。自主性是一项基础设施决策。

评估工作流

阶段 1：发现

收集项目当前状态的信息：

  1. 检查项目结构

    • 查找 CI/CD 配置（.github/workflows/、Jenkinsfile、.gitlab-ci.yml）
    • 检查容器化配置（Dockerfile、docker-compose.yml、devcontainer.json）
    • 确认测试基础设施（tests/、__tests__/、测试配置文件）
    • 查找环境管理文件（.env.example、requirements.txt、package.json）

  2. 审查开发工作流

    • 阅读贡献指南、README 或开发者文档
    • 检查沙箱／隔离模式
    • 查找数据库设置脚本或测试固件
    • 确认依赖项的管理方式

  3. 评估现有自动化

    • 审查现有 CI/CD 流水线
    • 检查自动化测试模式
    • 查找环境配置脚本
    • 确认清理／拆除流程
阶段 2：根据原则评估

对项目的每个维度评分（0-3）。详细评分标准见 references/assessment-criteria.md。

维度检查内容
沙箱隔离临时环境、容器支持、每次运行状态干净
数据库独立性本地数据库设置、代码中的迁移、无外部数据库依赖
环境可复现性明确的依赖项、无隐藏状态、确定性的设置流程
会话独立性远程执行能力、不依赖用户会话
面向结果的设计明确的验收标准、尽量减少流程耦合
直接接口CLI 优先的工具、操作系统原语、尽量减少抽象层
最小化框架开销简单接口、无繁重编排、可组合的 CLI 工具
状态显式化工作区目录、基于文件的产物、可检查的日志
基准测试可衡量的质量标准、自动化验证
成本意识资源限制、用量跟踪、明确的资源配置
输出可验证性自动化验证、确定性结果、明确的退出代码
基础设施限定的权限系统强制实施的约束、最小权限、无运行时提示
阶段 3：生成建议

对于评分低于 2 的每个维度，提供：

  1. 当前状态：目前已有的内容
  2. 差距：自主执行所缺少的内容
  3. 建议：具体、可执行的改进措施
  4. 优先级：根据影响和工作量评定为高／中／低

根据项目的以下方面制定建议：

  • 技术栈
  • 团队规模和工作流
  • 现有基础设施
  • 部署目标

输出格式

# Autonomous Agent Readiness Assessment

## Project: [name]
## Assessment Date: [date]

## Executive Summary

[1-2 paragraphs summarizing overall readiness and top priorities]

**Overall Readiness Score: X/36** (sum of dimension scores)

## Dimension Scores

| Dimension | Score | Status |
|-----------|-------|--------|
| Sandbox Isolation | X/3 | [emoji] |
| Database Independence | X/3 | [emoji] |
| ... | ... | ... |

Status: 0-1 = needs work, 2 = adequate, 3 = strong

## Detailed Findings

### [Dimension Name] (X/3)

**Current State:**
[What exists]

**Gap:**
[What's missing]

**Recommendation:**
[Specific action]

**Priority:** [High/Medium/Low]

[Repeat for each dimension]

## Prioritized Action Plan

### Immediate (This Week)
1. [Highest impact, lowest effort items]

### Short-term (This Month)
1. [Important foundational changes]

### Medium-term (This Quarter)
1. [Larger infrastructure investments]

## Quick Wins

[2-3 changes that can be made today with minimal effort]

核心原则参考

所有内容都在沙箱中运行

每次 Agent 运行都在独立、隔离、可销毁的临时环境中执行。环境干净，文件系统可写，可执行命令，并限制网络访问范围。验证输出后销毁环境。

不使用外部数据库

Agent 在沙箱内创建自己的数据库。按需安装软件包，在本地启动数据库，运行迁移，明确填充数据，并在结束时拆除。每次运行都可复现，且不共享状态。

环境垃圾确实存在

长期运行的环境会积累杂散文件、安装到一半的软件包、缓存状态和孤立进程。全新环境能暴露正确性问题；持久化环境则会掩盖这些问题。

不依赖用户会话运行

将 Agent 循环与浏览器标签页、终端会话和开发者机器解耦。启动任务，合上笔记本，回来即可查看已完成的产物。通过墙钟时间限制、资源限制和自动清理进行控制。

定义结果，而非流程

避免制定逐步计划和对工具进行微观管理。定义预期结果、验收标准和约束。规划和执行由 Agent 负责。

直接、底层的接口

直接访问命令执行、持久化文件和网络请求。优先使用操作系统原语，而非抽象层。命令行优先的系统比看起来更容易调试，也更强大。

明确持久化状态

提供可写的工作区目录，用于存放中间结果、日志、部分输出和规划产物。文件可供检查、结果具有确定性，并支持运行后分析。

尽早引入基准测试

尽可能早地引入基准测试。使用具有代表性且可重复的指标来衡量质量。即使是粗略的基准测试，也胜过没有。

尽量减少框架开销

大多数实际的 Agent 工作流都归结为运行命令、读写文件和发起网络调用。命令行优先的系统更容易推理和调试，也比看起来更强大。当抽象层比任务本身更复杂时，它就会成为瓶颈。

做好成本规划

预估令牌用量，明确分配算力，并通过系统强制实施限制。自主性只会改变成本出现的位置，并不会消除成本。

可验证的输出

输出必须无需人工审核即可验证。应具备自动化验证、确定性结果以及明确的成功／失败退出代码。如果无法衡量质量，就无法在自主运行中信任它。

权限受基础设施约束

权限由环境约束，而非提示词或运行时决策。明确授予能力，对危险操作实施沙箱限制，并默认采用最小权限。无需在运行时请求权限。

评论

支持 Markdown