mcpField
A
agent-architecture-analysis

agent-architecture-analysis

github.com/existential-birdsAgent 工作流85213 次安装11 周前更新
代码仓库

关于 agent-architecture-analysis

用于依据 12-Factor Agents 原则评估代码库中 Agent 架构的审查技能。它围绕 13 项因素收集证据并评分，整理差距与改进建议。

主要功能

  1. 01评估 13 项 Agent 架构因素
  2. 02搜索代码与文档中的证据
  3. 03按 Strong、Partial、Weak 评定合规性
  4. 04记录差距与可执行建议
  5. 05评分前执行硬性门槛检查

适用场景

  1. 01审查现有的 LLM 系统
  2. 02审计生产环境中的 Agent 应用
  3. 03评估新系统的架构决策
  4. 04规划 Agent 代码库的改进

安装

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

$npx skills add https://github.com/existential-birds/beagle --skill agent-architecture-analysis

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

附带文件references/factors.md

详细介绍

12-Factor Agents 合规性分析

参考：12-Factor Agents

输入参数

参数描述必填
docs_path文档目录的路径（用于已有的分析）可选
codebase_path要分析的代码库根路径必填

分析框架

每个因子的完整评分标准——包括原则、搜索模式、文件模式、合规标准（强／部分／弱）和反模式——位于 references/factors.md。在分析工作流中，请阅读其中相关因子的章节，了解要运行的搜索模式和评分标准。

#因子重点
1自然语言转工具调用来自 LLM 的经架构验证的结构化输出
2掌控自己的提示词将提示词作为一等、带版本控制且模板化的代码
3掌控自己的上下文窗口自定义格式化历史记录／状态／工具结果
4工具应产生结构化输出经验证的 JSON 触发确定性代码
5统一执行状态合并执行状态与业务状态的单一状态对象
6启动／暂停／恢复可启动、在任意位置暂停并恢复的 API
7使用工具联系人工将联系人工作为结构化工具调用
8掌控自己的控制流自定义路由／重试，而非使用框架默认设置
9将错误压缩进上下文将错误反馈以实现自我修复并进行升级处理
10小型、专注的 Agent职责范围明确，每个 Agent 执行 3-10 个步骤
11从任意入口触发CLI／REST／WebSocket／聊天／webhook 入口
12无状态归约器纯函数式 (state, input) -> (state, output) Agent
13预先获取上下文提前获取可能需要的数据

每个因子的完整评分标准，请参阅 references/factors.md。

输出格式

门槛顺序： 在满足适用因子的硬性门槛（见分析工作流之后）之前，不得评定强／部分／弱，也不得将建议视为观察到的事实。

执行摘要表
| Factor | Status | Notes |
|--------|--------|-------|
| 1. Natural Language -> Tool Calls | **Strong/Partial/Weak** | [Key finding] |
| 2. Own Your Prompts | **Strong/Partial/Weak** | [Key finding] |
| ... | ... | ... |
| 13. Pre-fetch Context | **Strong/Partial/Weak** | [Key finding] |

**Overall**: X Strong, Y Partial, Z Weak
各因子分析

对每个因子，请提供：

  1. 当前实现

    • 附带文件和行号引用的证据
    • 展示相关模式的代码片段

  2. 合规等级

    • 强／部分／弱及其理由

  3. 差距

    • 与 12-Factor 理想状态相比缺少的内容

  4. 建议

    • 可执行的改进措施及代码示例

分析工作流

  1. 初步扫描

    • 对所有因子运行搜索模式
    • 确定每个因子的关键文件
    • 记录现有的合规文档

  2. 深入分析（逐个因子）

    • 阅读已确定的文件
    • 根据合规标准进行评估
    • 附上文件路径记录证据

  3. 差距分析

    • 对比当前状态与 12-Factor 理想状态
    • 找出存在的反模式
    • 按影响程度确定优先级

  4. 建议

    • 提供可执行的改进措施
    • 包含改进前／后的代码示例
    • 如有路线图，请加以引用

  5. 总结

    • 汇总执行摘要表
    • 突出优势和关键差距
    • 建议改进的优先顺序

严格门槛（先证据，后评分）

按顺序执行。不要跳步：每项 通过 都是可核查的客观条件（磁盘上的路径、存在引用），而非主观确信。

  1. 扫描门槛 — 完成初始扫描（工作流第 1 步）后，通过： 对于每个因素（1–13），你都至少有 (a) 1 个要检查的仓库相对路径或 glob 命中，或 (b) 一行说明及其理由（例如搜索命令／输出，或“没有匹配项——代码库可能未涉及此问题”）。空泛敷衍（“看起来没问题”）无法通过此门槛。
  2. 证据门槛（逐项因素） — 在为该因素写下“强／部分／弱”之前，通过： “当前实现”至少包含 1 条引用，其中有 codebase_path 中的文件路径加上行号范围或简短摘录，或者明确说明经过针对性查阅后未找到证据。搜索后仍缺少证据时，除非该标准明确不适用（并说明原因），否则将该因素默认评为“弱”。
  3. 综合门槛 — 执行摘要表和逐项因素分析部分，通过： 只有在已满足范围内各因素的第 1–2 项门槛后才能编写。建议可以将新文件或模式作为提议，但不得将其作为已观察到的事实，除非有第 2 步的相应引用。

快速参考：合规性评分

评分含义行动
强完全落实原则维护，进行小幅优化
部分已落实部分内容，但仍有明显差距规划改进
弱落实极少或完全未落实在路线图中列为高优先级

何时使用此技能

  • 评估由大模型驱动的新系统
  • 审查 Agent 架构决策
  • 审计生产级 Agent 应用
  • 规划现有 Agent 的改进
  • 比较框架或实现方式

评论

支持 Markdown