用途：以 12-Factor Agents 原则作为工程视角（而非认证清单），规划或审计 LLM 工作流、智能体循环与工具调用应用，尽量把可安全、可重复判断的部分交给确定性代码。
模式：Design（规划新工作流或智能体功能）、Review（对已有代码或设计/规范给出发现）、Mixed（先审查现状再设计目标架构）。请求含糊时按现有产物推断：有代码或具体规范即 Review，只有期望结果即 Design。输出需声明所选模式。
范围：覆盖应用架构，包括提示、上下文构建、结构化模型输出、确定性执行、状态、控制流、暂停/恢复、人工介入、重试、触发与可重放性。不替代安全威胁建模、模型评估、可观测性埋点、性能分析与具体框架实现指南，相关项应作为后续工作提示。
主要流程：先确立系统边界，画出 trigger→canonical event→state/context builder→model decision→schema/policy validation→deterministic handler→persisted event/state→response/pause/next turn 路径；再逐一检查十二个因子及 Factor 13 附录，分为 Required、Recommended、N/A；区分观察与建议，观察需证据（file:line、精确配置/模式/端点/事件定义、设计文档摘录或运行时 trace），范围不完整时标为 Unverified 而非 Gap；按后果而非因子编号定级 Critical/High/Medium/Low。
Design 模式先确定 LLM 与代码的决策边界，定义类型化输出、确定性处理器、可重建运行的持久事件/状态模型、提示与上下文输入、启动/暂停/恢复/超时/取消/人工响应路径、有界重试与升级，以及关键状态迁移的重放或评估方式，用 assets/design-template.md 输出。Review 模式定位入口、模型调用、提示/上下文构建、工具模式、处理器、状态持久化、重试、人工关卡与测试，优先用 rg 并查看被引用文件，依次通过扫描门与证据门，把发现对应用户可见故障，建议最小架构改动。
加载参考：详细分析前读 references/factors.md；仅在需要更深代码搜索、企业审计/幂等/高风险副作用、脚手架/可观测性/评估/故障模式，或与其他 12-factor-agent 技能比较时读 references/extensions.md。
限制与注意：因子是原则而非合规标准，不应计算百分比或宣称“12-factor compliant”；Factor 13 是附录/附赠，不得当作正式第十三因子；使用框架不必然算失败，关键在能否检查和控制系统；内联提示不一定弱；原始聊天消息仅在有界、及时、过滤且可复现时才无碍。静态代码无法证明运行时行为，动态输入应请求 trace 或标 Unverified。方法论源自 Dexter Horthy / HumanLayer 的 12-Factor Agents，本文档为 CC BY-SA 4.0 下的改编。