阿里面试：AI 编程框架CC、Hermes、SpecKit、Superpowers、Paperclip 怎么选？你用过哪些？

公众号名称：技术自由圈

作者名称：尼恩塔尖AI团队

发布时间：2026-06-17 11:45

FSAC未来超级架构师

架构师总动员
实现架构转型，再无中年危机

尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！

Harness 架构已经是架构面试的核心题目，前两天就有个小伙伴面阿里，问到很多 AI coding框架的面试题，比如:

“用过哪些 AI coding框架? 用过 CC（claud code）吗?
用过 Hermes吗?
用过 SpecKit吗?
用过 Superpowers 吗?
用过 Paperclip吗？
Hermes+Claude全场景通用吗，可以什么场景都往上套吗?
SpecKit和Superpowers的核心区别是什么？为什么经常搭配在一起用？
Hermes+Claude是不是当前最强的Agent开发组合？
Paperclip和LangGraph这类编排框架有什么区别？
“AI coding框架CC、 Hermes、SpecKit、Superpowers 与 Paperclip 怎么选？

尼恩透露一下，答案都在后面。

尼恩有很多面架构、或者面大厂的学员，在终面，直接折戟在这类 AI coding框架的使用上，太可惜了。

通过这个系列的文章，这里尼恩给大家做一下系统化、体系化的梳理，写一个系列的文章组成尼恩编著 《 AI coding框架学习圣经》 深入剖析 Harness AI 平台级架构的架构思维与核心源码，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

同时，也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

阿里面试：AI coding框架CC、 Hermes、SpecKit、Superpowers 与 Paperclip 怎么选？

现在很多面试官，一开口就提问：先聊聊你接触过哪些主流的AI coding框架？分别是做什么的？怎么选型？

这是 Agent 开发、工程化岗位的开场必考题。

很多候选人直接报菜名：“用过 Claude Code（CC），用过 Hermes，了解 SpecKit，也看过 Paperclip。个人开发用 Hermes，大项目上 SpecKit，多 Agent 协作用 Paperclip。”

这句话很难拿高分。

因为它只回答了“用什么”，没有回答“为什么这么用”。

面试官真正想听的，不是工具清单，而是你能不能把这些工具放回工程化架构里，看清它们的职责、边界和组合关系。

这道题常见的失分点有两个：

第一，把不同层级的工具放在同一张桌子上比强弱。Hermes、SpecKit、Superpowers、Paperclip 解决的不是同一类问题，直接问谁更强，本身就是错位比较。

第二，只背结论，不讲约束。个人项目为什么可以轻？交付项目为什么要重？中型团队为什么常常要折中？这些说不清，面试官再追问一句“如果是 5 人团队两周上线呢”，答案就会散。

这类题真正考察的两点：一是否熟悉提到的工具，二是如何根据实际场景选择不同的工具进行组合。

Agent 工程化工具链选型，不是挑最强工具，而是看当前场景缺哪层能力。

不同场景里的任务复杂度、协作规模、合规要求、成本预算不同，工具链自然就不一样。约束弱就轻装上阵，约束强才逐层加治理。

面试官真正想听的，不是工具清单，而是你能不能把这些工具放回工程化架构里，看清它们的职责、边界和组合关系。

不同场景里的任务复杂度、协作规模、合规要求、成本预算不同，工具链自然就不一样。约束弱就轻装上阵，约束强才逐层加治理。

本文的前置 AI编程知识：

AI编程王炸组合：顶级三剑客 OpenSpec 定方向，Superpowers定纪律，Harness定协同

大厂全面开始 AI 编程机考：VibeCoding AI编程 7 大经典步骤，吊打阿里、美团等大厂的全面 AI 机考损招（史上最全）

逆天！Hermes +Claude 实现 AI 编程 Agent Team 硅基团队，一人开启 10个Agent的boss 之路

最高裁95%，只留5% 用AI的，某上市公司全面ai化。你的岗位，AI入侵指数是多少？多久消失？

2025年AI将能写 90%的代码。10年内，整个程序员行业，将系统性坍塌/雪崩/塌方!!!

第十四章：架构哲学和思维： Harness /ReAct /PlanExec /Reflect /混合范式的区别

架构哲学和思维： Harness /ReAct /PlanExec /Reflect /混合范式的区别

第十五章： Harness 底层知识： MCP与FC的10大差别？Harness 怎么用MCP与FC？

Harness 底层知识： MCP与FC的10大差别？Harness 怎么用MCP与FC？

第17章： Harness SDK 架构：DeepAgent 基于LangGraph的生产级Super Agent驾驭层实现

第18章：DeepAgent ：基于LangGraph的 Harness 执行层生产级子智能体 Sub-Agent 深度拆解

第18章：DeepAgent ：基于LangGraph的 Harness 执行层生产级子智能体 Sub-Agent 深度拆解

第19章：深入解析DeepAgents的Middleware管道：设计一个Harness 护栏完成Agent全生命周期的治理

第19章：深入解析DeepAgents的Middleware管道：设计一个Harness 护栏完成Agent全生命周期的治理

第20章： DeepAgents 经验注入+记忆注入：基于Memory与Skills双中间件实现渐进式披露 + 运行时经验注入

第20章： DeepAgents 经验注入+记忆注入：基于Memory与Skills双中间件实现渐进式披露 + 运行时经验注入

第21章：【顶级架构思维】Harness 架构如何上下文压缩：深入剖析 DeepAgents 四级上下文压缩流水线底层原理和核心源码

【顶级架构思维】Harness 架构如何上下文压缩：深入剖析 DeepAgents 四级上下文压缩流水线底层原理和核心源码

第22章：Hermes +Claude 实现 AI 编程 Agent Team 硅基团队，一人开启 10个Agent的个人boss 之路

第24章：【顶级架构】穿透Hermes 塔尖工具系统：自注册设计+ 组合式按需推送+四层纵深防御+零配置插件 +常驻事件循环

第24章：【顶级架构】穿透Hermes 塔尖工具系统：自注册设计+ 组合式按需推送+四层纵深防御+零配置插件 +常驻事件循环

第25章：【Harness顶级架构】Hermes skills 自进化秘诀：三层引擎 + 影子Agent + 边车文件 + 伞状合并

其他的高质量文章，估计有 10章以上，具体请关注技术自由圈。

尼恩还在写，后续发布

一、CC、 Hermes、SpecKit、Superpowers 与 Paperclip 简介

很多团队在工具选型上会出现一个基础误判：还没有弄清工具本身的产品形态，就把它们放在一起横向比较强弱。

有人问“Superpowers和Hermes哪个写代码厉害”，有人问“Paperclip能不能当Claude用”，本质都是认知错位。

这五类工具从产品形态上就不是一类：有的是独立软件，有的是运行时框架，有的是工具包，有的是插件，也有的是管理平台。

它们分属工具链的不同层级，不存在简单“二选一”的关系。

工具名称	产品形态	所属层级	核心角色定位	是否可独立运行
Claude Code	官方终端CLI编程软件	模型与编码执行层	底层自主编码执行底座	是，开箱即用
Hermes	可自部署的Agent运行时框架	个人Agent运行时层	给编码Agent补记忆、技能与自动化	否，需对接大模型
SpecKit	规格驱动开发工具包（模板+校验）	规格与事实源层	标准化需求与任务，做单一事实源	否，需配合编码Agent使用
Superpowers	可插拔的Agent技能插件集	工程纪律层	给编码Agent补标准化工程能力	否，需加载到支持的Agent中
Paperclip	可自部署的多Agent管理平台	多Agent编排与治理层	统一调度、管控多Agent与多项目	是，需部署后通过UI/API使用

这五类工具不是同类竞品，而是从下到上的叠加增强关系。

底层是执行软件，往上依次加运行时框架、规范工具包、纪律插件，最上层是管理平台。缺哪一层补哪一层，不是选一个就排除其他。

1.1 Claude Code：Anthropic官方终端原生编程软件

真正落项目时，Claude Code给人的第一感受很直接：它不是IDE里那个“帮你补两行代码”的助手，而是一个能直接下场干活的终端程序员。

它是Anthropic官方出的独立命令行（CLI）编程工具。装完就能在终端里用，不需要自己部署服务，也不需要先接一堆外围工具。

官方把它定义为「Agentic coding assistant」，这个定位其实很关键：它不是聊天机器人，也不是代码补全插件，而是有系统权限、能读仓库、改文件、跑命令、做验证的编码Agent。

Claude Code 是独立 CLI 程序，具备读写文件、执行 shell、全仓库理解、自主编码闭环能力，无持久记忆，单次任务闭环。

来一个 Claude Code 最小最小实操 Demo

第一步，安装：

# 官方安装脚本
npm install -g @anthropic-ai/claude-code
# 配置 API Key
export ANTHROPIC_API_KEY=sk-xxx

场景 Demo：给项目新增用户查询接口（单次任务）

第2步，进入代码仓库根目录

cd ./nodejs-user-server

第3步，直接下发任务指令

claude-code "分析当前项目目录结构，在 routes/user.js 新增 GET /api/user/:id 接口，包含参数校验、数据库查询、异常捕获，写完自动运行 npm test 自测验证"

Demo 效果

(1) 自动读取 package.json、路由文件、数据库配置；

(2) 自动编写接口代码；

(3) 自动执行测试命令，发现报错自行修改代码；

(4) 会话关闭即状态销毁，下次执行需要重新介绍项目背景。

放到整条工具链里看，Claude Code就是最底层的执行载体。上层不管是Hermes、SpecKit还是Superpowers，最后都得落到“谁来改代码、谁来跑测试、谁来修报错”这个问题上。这个动作，还是要靠它这类执行工具完成。

它真正好用的地方，主要集中在执行端：

(1) 全仓库级代码理解：自动扫描整个项目的目录结构、依赖关系、架构逻辑，建立完整的代码心智模型，支持跨文件修改、全库重构、依赖联动调整，不是只能单文件补代码。

(2) 全链路自主执行闭环：拥有完整的文件读写权、终端命令执行权、网络访问权。接收需求后可以自主拆解步骤、写代码、跑构建、执行测试、排查报错、修复问题。实际用下来，中等复杂度任务里，人工不再需要逐行指挥，更多是在关键节点做确认。

(3) 长上下文支撑：配套Claude 4系列模型的百万级token上下文，中小型项目可全量装载，长任务过程中保持需求、约定的连贯性。

(4) 内置工具调用体系：原生支持文件操作、命令执行、网页抓取、搜索等基础工具，也支持自定义扩展工具，满足定制化执行需求。

Claude Code强在单次任务执行，弱在长期记忆、流程约束和团队治理。

新开一个会话，很多项目背景、历史约定、团队偏好还是要重新同步；它也不会天然强制TDD、强制评审，质量很大程度依赖模型自觉和人的把关；至于多项目、多Agent、预算、权限这些管理问题，就更不是它这层该解决的事。

所以我会把它放在这几类场景里：临时调试、单次开发任务、中小型个人项目、快速原型验证。越是“马上改、马上验、马上结束”的活，它越合适。

面试里如果被问到“Claude Code和Cursor这类IDE补全插件有什么区别”，不要只说“Claude更强”。更稳的说法是：两者的运行形态和工作模式不同。

IDE插件运行在编辑器沙箱里，更多是人主导、AI辅助；
Claude Code是独立终端工具，有完整系统权限，可以自主执行命令、操作文件、调用外部工具。
前者更像助手，后者更像 结对程序员。

如果面试官继续追问“既然Claude Code已经能独立开发，为什么还要上层工具”，答案也很简单：它解决的是“单次任务能不能做完”，解决不了“长期项目怎么记住经验”“团队开发怎么统一质量标准”“多项目多Agent怎么管控”这三件事。上层工具是补短板，不是替代它。

1.2 Hermes Agent：可自部署的个人Agent运行时框架

Hermes要先摆正位置。它不是另一个Claude Code，也不是开箱即用的编码软件。它更像一个长期运行的个人Agent后台。

它由Nous Research开源，可本地化部署，本身不内置大模型，需要对接Claude、GPT等模型服务。部署之后，它可以通过CLI、聊天软件等多端接入，长期在后台跑。官方把它定位为「self-improving autonomous agent」，也就是可自我进化的自主智能体。

Hermes Agent 是运行时增强层，补充跨会话持久记忆、技能沉淀、后台自动化，依赖 Claude Code / 大模型做执行，不具备原生编码能力。

来一个 Hermes Agent 最小最小实操 Demo

第一步，拉取部署 Hermes

git clone https://github.com/nousresearch/hermes.git
cd hermes
npm install
# 配置模型指向 Claude Code 底座
cp config.example.yaml config.yaml

修改 config.yaml 核心配置（对接 Claude Code）

model_provider: anthropic
api_key: ${ANTHROPIC_API_KEY}
executor_backend: claude-code
memory:
  core_memory_files:
    - MEMORY.md   # 项目长期约定
    - USER.md     # 个人编码偏好

第2步，初始化核心记忆文件

MEMORY.md
项目：nodejs-user-server
技术栈：Node.js + Express + Mongoose
编码规范：必须写入参校验、try/catch、接口注释、单元测试
已有路由：/api/login /api/register
USER.md
偏好：缩进2空格，错误统一返回 {code,msg,data}，拒绝松散裸返回

第3步，Hermes 下发任务 Demo

# 启动后台常驻 Hermes
node index.js daemon
# 新开终端发任务
hermes chat "给用户接口新增分页查询用户列表接口"

Demo 运行效果印证理论

(1) Hermes 自动加载两份核心记忆，无需重复讲解项目、规范；

(2) 任务执行自动调度底层 Claude Code 完成编码 + 自测；

(3) 执行完毕自动把本次设计思路、踩坑点存入历史检索记忆；

(4) 多次迭代后自动提炼「分页接口开发技能」存入技能库，同类任务速度越来越快。

Demo 总结

Hermes = 运行时增强层 (包括记忆管理)，Claude Code = 干活执行者，二者是调度从属关系，不是竞品。

这个定位听起来有点大，但落到工程里，其实就是三件事：记住上下文、沉淀技能、后台自动化。

Claude Code负责一次次把任务做完，Hermes负责把这些任务里的经验留下来，让下一次不再从零开始。

它的设计重点在记忆和运行时增强上：

【1】三层结构化记忆体系

这是它最核心的设计，也是和原生编码工具最本质的区别：

核心置顶记忆：通过MEMORY.md（项目约定与工具经验）、USER.md（用户偏好与沟通习惯）两个硬上限文件，永久保存高价值信息，每次会话自动注入上下文；
会话检索记忆：历史对话全量存入本地SQLite数据库，通过FTS5全文检索按需召回，解决上下文溢出问题；
技能化长期记忆：从执行经验中自动抽象标准化技能，存入技能库，同类任务直接复用，不用重复引导。

【2】自进化学习闭环

支持从执行结果中自动总结经验、优化技能，运行越久、同类任务处理越多，执行速度和准确率越高，实现“越用越懂你”的效果，这也是“自进化”的核心含义。

【3】后台常驻与多端接入

支持后台daemon常驻运行，可配置定时任务、触发式任务，无人值守执行巡检、部署、日志整理等自动化工作；支持CLI、Telegram、Slack等多端接入，不用本地登录也能下发任务。

Hermes的优势很鲜明：记忆能力强、自动化程度高、本地化部署隐私性好、适合长期持续进化。

我会把它放在个人长期项目、自动化运维脚本、私人工作助理、多端触达任务这些场景里。

但Hermes也不是万能的。

Hermes 本身不负责底层编码推理，必须对接大模型和执行工具；它偏单用户设计，没有强制工程纪律，也没有团队级权限、审计和协作机制。拿Hermes去扛多人强交付项目，很容易变成每个人都有一套自己的记忆，最后口径对不上。

面试里讲Hermes，最容易被追问两个点。

第一个是“它和Claude Code到底什么关系”。

大家可以直接说：二者是增强与被增强的关系，不是竞品。
Claude Code负责落地执行，Hermes负责运行时增强层，比如记住用户习惯、沉淀过往经验、调度后台任务。
一个干活，一个攒经验。

第二个是“记忆为什么要有硬上限”。这其实是很典型的工程取舍。

置顶记忆要的是高权重、低噪声，不是越多越好。
如果什么都往里塞，过期信息和临时结论会稀释真正重要的项目约定。
没有上限的记忆系统，时间一长就会熵增，检索噪声变大，最后还不如不用。
有界记忆，本质上是用容量换稳定性。

1.3 SpecKit：规格驱动开发工具包

SpecKit解决的是另一个老问题：AI写代码很快，但需求边界经常飘。

它是GitHub官方开源的规格驱动开发（SDD）工具包，不是独立运行的软件，也不是一个能自己写代码的Agent。

SpecKit 是需求规范层，产出唯一事实源 Spec 文档，约束需求边界，防止需求漂移，必须搭配编码 Agent 使用，不能独立写代码。

来一个SpecKit 最小最小实操 Demo

第一步初始化 SpecKit

npm install -g @github/speckit
# 项目初始化规格目录
speckit init
# 生成三种规格模板：full / light / minimal

第2步 SpecKit Demo 场景：迭代「用户分页接口」，走 Spec 闭环

1 发起规格生成命令

speckit new feature "用户分页查询接口迭代" --template light

SpecKit 交互式引导填写需求，自动生成 specs/feature-user-page.query.md，结构示例：

# 需求规格（唯一事实源）
(1) 业务目标：支持分页查询全部用户

(2) 入参：pageNum、pageSize，非负整数校验

(3) 出参结构：total、list、pageNum、pageSize

(4) 异常规则：参数非法返回400，数据库异常返回500

(5) 验收用例3条

2 规格校验通过

speckit validate specs/feature-user-page.query.md
# 校验不通过会拦截，要求补全需求边界

3 绑定 Claude Code 基于 Spec 开发

claude-code "严格参照 specs/feature-user-page.query.md 规格实现代码，所有变更必须匹配spec要求，写完做一致性校验"

4 开发完成反向校验代码与 Spec 是否对齐

speckit check-align specs/feature-user-page.query.md

SpecKit Demo 直观体现核心价值

多人协作所有人以同一份 Spec 为准，杜绝「理解不一样」；
需求变更必须修改 Spec，再改代码，变更可追溯；
小需求可用 minimal 极简模板降低流程成本，避免过度设计。

更准确地说，SpecKit是一套规格模板、校验规则和工作流规范，需要配合Claude Code这类编码Agent使用，嵌入到开发流程里，负责生成、校验、管理规格文档。

官方叫它「spec-driven development toolkit」，这个名字说得比较准：

它不是为了多写几份文档，而是把规格从一次性沟通材料，变成项目里的可执行工程资产。
尤其在AI开发里，它要解决的就是“氛围编程”带来的需求漂移、理解偏差和交付不可追溯。

它的能力不是写代码，而是把开发前的标准定清楚：

(1) 标准化规格生成链路：内置五阶段标准化模板：规则定义→需求澄清→规格设计→计划拆解→任务拆分，引导Agent一步步输出结构化的spec文档，而不是一句话直接写代码。每一步都有校验规则，不符合规范无法进入下一环节。

(2) 单一事实源校验机制：生成的spec文档是整个项目的唯一标准，后续所有代码、测试、评审都必须和规格对齐。工具自带lint校验能力，代码与规格不符会自动拦截，从流程上避免AI写着写着偏离需求。

(3) 多粒度模板适配：提供全量、精简、极简三种粒度的规格模板，不是只能走重型流程。小项目可以用极简模板，只保留核心需求和任务拆解；大型交付项目用全量模板，覆盖完整的设计、接口、测试约定。

SpecKit的价值在多人协作里会特别明显。

它能从根源统一需求认知，减少反复返工；全链路可追溯，也更容易满足合规审计；模板还能裁剪，不同规模项目可以选不同粒度。

但它只管需求和规格，不管执行过程。

它不会替你写代码，也不会天然保证Agent一定按工程纪律做事。所以它必须配合编码Agent使用，复杂场景还要搭配Superpowers。全量流程也有成本，极小需求、临时修复、小范围试验，强行上SpecKit就会变重。

面试里如果被问“SpecKit能不能单独开发”，答案要干脆：不能。

它是工作流工具包，作用是给编码Agent加规格约束，相当于施工图。
没有执行Agent，它只能生成文档，不能落地代码；
没有SpecKit，执行Agent又容易需求漂移。
二者是流程约束和落地执行的配合关系。

如果被问“Spec-Driven Development和传统瀑布文档有什么差别”，不要只说“更自动化”。关键差异有三个：

传统文档是辅助沟通，spec是全生命周期的唯一事实源；
传统文档主要是人写人看，spec是人和AI共同遵循的标准；
传统文档经常写完就放一边，spec要随着项目持续迭代，代码、测试、评审都要回到它上面校验。

1.4 Superpowers：可插拔的编码Agent工程技能插件集

如果说SpecKit管“做什么”，Superpowers管的就是“别瞎做，按工程规矩做”。

Superpowers 基于Agent Skills开放标准，本质是一组技能插件集合，不是独立软件，也不是框架。

它可以加载到兼容Agent Skills协议的编码Agent里，比如Claude Code、Hermes，给Agent补上标准化工程能力。

作者给它的定位是「software development methodology for AI coding agents」。这句话翻成工程语言就是：把资深工程师平时会坚持的开发方法，封装成Agent能自动触发的技能。它不是高级Prompt包，而是让AI在该澄清的时候澄清、该写测试的时候写测试、该调试的时候调试、该评审的时候评审。

它的能力主要体现在三类技能上：

【1】14项标准化工程技能： 覆盖从需求到交付的全流程，核心分为三类：

流程规划类： 设计澄清、任务拆解、计划执行，要求Agent先完成必要分析再进入编码，避免直接进入实现导致返工；
质量保障类： TDD测试驱动、系统化调试、结果验证、代码评审，强制按工程纪律执行，守住质量底线；
协作规范类： 分支管理、提交规范、子任务拆分，对齐团队协作标准。

【2】自动触发机制： 不是需要手动调用的命令，是内置的行为约束。

比如只要Agent开始写功能代码，TDD技能就会自动触发，强制先写测试用例，再写业务实现，跳步就会被拉回流程，不用人每次提醒“要写测试”。

【3】全兼容可插拔： 兼容所有支持Agent Skills协议的Agent，即插即用，不需要改原有流程。

可以全量加载，也可以只选单个技能加载，灵活度很高。实际价值不是“多几句提示词”，而是让测试、调试、评审这些动作稳定出现，减少靠人反复提醒。

Superpowers 是执行流程约束层，前置拦截开发步骤，强制 TDD、代码评审、自测、规范提交，管住「开发过程不走样」，可注入 Hermes / 原生 Claude Code。

来一个 Superpowers 最小使用 Demo

第一步：安装引入 Superpowers

# 拉取技能仓库
git clone https://github.com/agent-skills/superpowers.git
# Hermes 配置加载 Superpowers 技能集
# 修改 hermes config.yaml
skill_plugins:
  paths:
    - ./superpowers/skills
  enable_skills:
    - tdd-first
    - code-review-self
    - commit-lint

开启三个核心技能：

(1) tdd-first：必须先写测试用例，再写业务代码，禁止直接写实现

(2) code-review-self：编码完成自动自检逻辑、漏洞、边界

(3) commit-lint：Git 提交必须符合 Angular 规范

第2步：带 Superpowers 任务执行 Demo

hermes chat "基于现有用户模块，新增禁用用户状态字段"

执行步骤（Superpowers 强制拦截流程）

(1) 触发 TDD 技能：先梳理测试场景，生成单元测试用例；

(2) 强制写完测试用例并跑通，才允许编写业务代码；

(3) 代码写完自动触发自评审，提示潜在边界问题并修复；

(4) 提交 Git 时校验 commit 格式，不合规直接拦截提交。

Dem 结论

SpecKit：事前定「做成什么样子」（需求标尺）
Superpowers：事中管「按什么步骤做」（过程护栏）二者搭配形成完整需求 + 执行双锁闭环。

Superpowers的优势是轻、便宜、无侵入。加载之后就能提高代码质量下限，很适合中小型项目质量兜底、个人开发标准化，或者不想上重型规范但又想保住质量底线的折中场景。

它只约束执行过程，不定义需求规格；它属于引导式约束，没有SpecKit那种规格事实源的硬约束；它不能独立运行，必须依赖底层编码Agent。

面试里问“它和SpecKit有什么区别”，我会这样答：

SpecKit管需求端，定“做什么、做成什么样”；
Superpowers管执行纪律，定“怎么做、按什么流程做”。

一个定目标和标准，一个卡流程和纪律。二者经常搭配，是因为它们刚好补的是不同短板。

再往深问，“为什么不直接写系统提示词”，这里就要讲工程化了。

提示词是单次的，长会话中会被稀释；
技能是常驻触发的，更稳定。
提示词靠人写，团队里每个人质量不一样；技能是标准化封装，团队标准更统一。

提示词更多是提醒，技能可以做流程校验和步骤拦截。

简单说，提示词像口头要求，技能插件更接近固化的流程制度。

1.5 Paperclip：可自部署的多Agent编排管理平台

Paperclip放到最后讲，是因为它已经不是“写代码工具”了。

Paperclip 管的是组织和治理。

它是开源的多Agent组织化管理平台，可以独立部署成完整Web应用，包含前端管理界面、后端服务和数据库存储。部署之后，可以通过UI创建Agent团队、配置任务、管预算、看审计日志。它是管控层产品，不是执行层工具。

官方slogan是「open-source orchestrator for zero-human companies」。

这个说法可以不用太玄乎，工程上就理解成：单个Agent像员工，Paperclip像公司的管理体系，负责组织架构、任务分派、进度追踪、成本管控和合规审计。

Paperclip 是顶层治理控制平面，负责：多 Agent 组织编排、任务调度、预算管控、权限、审计，无编码能力，接入下层任意执行链路。

来一个 Paperclip 最小部署 + 多 Agent 编排 Demo

第一步，部署 Paperclip 平台：

git clone https://github.com/paperclip-org/paperclip-platform
cd paperclip-platform
docker-compose up -d
# 访问后台：http://localhost:8080

第二步，平台配置 Demo 架构：

在后台创建组织架构：

(1) 架构统筹 Agent

(2) 需求校验 Agent（绑定 SpecKit）

(3) 开发执行 Agent（绑定 Hermes + Claude Code + Superpowers）

(4) 审计复盘 Agent

设置全局 Token 预算、文件读写权限隔离、操作审计日志开关

第三步，下发跨角色完整需求 Demo

平台创建项目任务：用户模块整体重构迭代

(1) Paperclip 调度架构 Agent 拆解整体方案；

(2) 分发子任务给需求 Agent 生成并校验 Spec；

(3) 分发开发任务给执行 Agent 落地编码，Superpowers 约束开发流程；

(4) 全部完成后调度审计 Agent 全链路复盘留痕；

(5) 平台实时查看每个 Agent 消耗 Token、进度、操作日志，超预算自动暂停任务。

Paperclip 是管理者，不写代码；下层 Hermes/Claude/SpecKit/Superpowers 是执行干活单元，平台只做调度与治理。

项目和Agent一多，靠人工盯进度、看日志、控预算就会乱，Paperclip就是为这个阶段准备的控制平面。

Paperclip 的能力重点是组织化和治理：

【1】组织架构化编排： 支持搭建层级化的Agent团队，从CEO Agent、部门负责人Agent到执行Agent，权责清晰、任务逐级拆解分派，模拟真实企业的组织管理模式，而不是零散的单个Agent。

【2】心跳式任务调度： 所有Agent基于心跳协议运行，定时唤醒、自主推进任务、同步进度，支持定时触发、Webhook触发、API触发等多种模式，可实现7×24小时无人值守运营。

【3】全维度治理能力： 这是它作为平台的核心价值：

预算管控： 可给团队、项目、Agent分级设置Token预算，超支自动停止，避免成本跑飞；
权限隔离： 不同角色Agent配置不同的系统、文件权限，降低安全风险；
审计回放： 所有任务执行全链路留痕，支持日志回放、问题追溯，满足合规要求；
异常重试： 任务失败自动重试、自动升级，减少人工运维成本。

【4】底层执行工具兼容： 不绑定任何执行端，Claude Code、Hermes、Spec Kit+Superpowers等都可以作为执行节点接入平台。上层统一治理，下层按需选择执行流，一套平台管理所有类型的项目。

Paperclip的优势，是能把零散Agent变成有序团队，实现多项目、多Agent的规模化管控。它适合多团队多项目并行、Agent规模化落地、需要统一成本与权限管控、平台级Agent运营这些场景。

Paperclip本身没有任何编码执行能力，完全依赖底层执行Agent；它还需要服务器、数据库和运维配套，配置和学习成本都不低。单人单项目、小团队临时需求，上它通常就是过度设计。

面试里如果被问“Paperclip是不是更高级的编码Agent”，一定要先纠偏：不是。它是管理平台，管的是Agent，不是直接写代码。它也不能替代Hermes，Hermes是执行层的个人运行时，负责单个Agent的记忆和自动化；Paperclip是治理层的管控平台，负责调度多个Agent和多个项目。实际落地里，常见做法是Paperclip在上面管控，下层接Hermes或Claude Code这类执行节点。

如果拿它和LangGraph比，差异也不在“谁更强”，而在产品形态。LangGraph是代码级开发框架，面向开发者，提供图编排、状态机这些基础能力，灵活度高，但管理界面、权限、预算、审计要自己做。Paperclip是产品化平台，面向团队管理者，开箱带组织、调度、治理能力，但灵活度相对有限。想深度定制，就用框架自己搭；想快速落地治理，就用平台能力。

1.6 小结：一张表分清五个工具

最后再用一张表收束，面试时按这个逻辑表达，基本不会混淆：

工具名称	通俗类比	核心作用	记住一句话
Claude Code	干活的程序员	落地写代码、做执行	底层干活的，所有工具最终都靠它落地
Hermes	程序员的私人助理	帮程序员记东西、攒经验、跑后台	给单人Agent加记忆加自动化
SpecKit	产品+需求分析师	定需求、定标准、画施工图	管“做什么”，防止需求跑偏
Superpowers	技术主管	定开发流程、卡质量底线	管“怎么做”，防止执行走样
Paperclip	公司管理体系	管团队、管预算、管进度、管审计	管“团队怎么运作”，多项目统一治理

归根结底，选型就是看项目缺哪类能力，再补对应的工具。缺什么补什么，复杂度和约束强度匹配，方案才站得住。

二、工具链分层架构与组合特性

Agent工具链和我们做后端架构是一个逻辑——分层解耦、按需叠加、能力互补。

不是层数越多越高级，刚好匹配项目的约束强度，才是最优解。

2.1 四层标准分层架构

这套分层不是凭空画出来的概念图，而是行业在几轮实践之后沉淀下来的工程结构。

最早大家只用原生编码工具，解决“能不能写代码”的问题；
后来发现长期项目反复同步上下文成本太高，于是加了运行时层解决记忆和效率问题；
再后来发现AI写出的代码质量不可控、多人协作容易失焦，又加了规范纪律层解决质量和对齐问题；
最后项目和Agent数量上来之后，才需要编排治理层解决规模化管理问题。

从下到上看，项目越简单，需要的层数越少；约束越强、规模越大，才需要继续叠加治理能力。

面试时把这套演进逻辑讲清楚，比单纯背工具名更能体现工程判断。

这套分层核心是把四类问题彻底分开：

执行层解决「代码能不能写出来」的问题
运行时层解决「长期开发能不能提效」的问题
规范纪律层解决「写出来的东西能不能达标」的问题
编排治理层解决「多项目多团队能不能管好」的问题

图里最关键的是两条回路：经验要沉淀回运行时层，校验失败要回退到执行环节。

没有这两条回路，工具链就只是“一次性自动化脚本”，谈不上工程化。

第0层：模型与编码执行层

这是所有能力的底座，真正做代码生成、推理、工具调用、自主执行的都在这一层。

代表产品是Claude Code这类独立终端编程软件，以及Cursor、Windsurf这类IDE内置Agent，还有OpenAI Agents SDK这类开发框架。

它的核心价值就是纯粹的执行效率：单任务快、开箱即用、没有额外部署和配置成本。很多人会低估原生工具，觉得太简单、缺少架构感。

实际项目里，大量临时调试和一次性小需求，打开就写，反而比套几层框架更高效。架构的克制，很多时候比加功能更考验水平。

相关问题：

**Q：**什么场景下完全不需要上层Agent框架，只用原生编码工具就够了？

一次性短任务、临时调试、小功能开发，用原生编码工具就够了。

判断标准主要看三点：

任务生命周期短，未来不会反复迭代；
单人执行，不需要多人对齐标准；
没有强质量、强审计要求。

满足这三点，原生工具通常是更合适的选择，额外叠加上层框架反而会变成流程成本。

很多团队为了显得“工程化”，改个单行bug也要开全套框架，工具启动和上下文准备的时间已经超过修复本身，这就本末倒置了。

第1层：个人Agent运行时层

核心是给执行层补记忆、补自动化能力，代表工具是Hermes Agent运行时框架。原生执行工具都是无状态的，关了会话就全忘，下次打开还要重新讲项目背景、编码习惯、踩过的坑，长期项目反复做无用功。

这一层就是解决这个问题：跨会话的持久记忆、自动沉淀的可复用技能、后台常驻的定时任务，相当于给单个开发者配了个能记住所有习惯的专属助理。

相关问题：

**Q：**Hermes和原生Claude Code最本质的区别是什么？

二者根本不在一个层级，解决的不是同一个问题。

Claude Code是执行层编码软件，解决「单次任务怎么完成」的问题，用完即走、偏无状态；
Hermes是运行时增强框架，解决「长期开发怎么持续提效」的问题，有记忆、能沉淀技能，也能做后台自动化。

简单说，Claude Code负责执行动作，Hermes负责沉淀记忆和经验。很多人把二者当竞品比较，本质上是没有分清执行层和运行时层。

第2层：规范与工程纪律层

这一层管的是质量和可控性，不是一个工具，是两个互补组件配合：SpecKit规格工具包 + Superpowers技能插件。很多人搞不清二者的关系，其实就是一前一后两道关：

SpecKit管“做什么”，把需求、接口、任务拆解固化成统一的spec文档，作为唯一事实源，从源头避免需求漂移、各写各的；
Superpowers管“怎么做”，把TDD、调试、评审这些工程纪律封装成可插拔技能，从执行层面约束流程，减少跳步骤、漏校验的问题。一个定标尺，一个装护栏，二者是互补，不是替代。

相关问题：

**Q：**SpecKit和Superpowers有什么区别？为什么总是搭配着用？

SpecKit管需求规格，Superpowers管执行纪律，二者一个管起点，一个管过程，单独用都有明显短板。

SpecKit钉死「做什么、做成什么样」，是统一的事实源，但它管不了执行过程。AI完全可以对着规范偷工减料，跳测试、省校验，规格写得再好，落地打折扣也没用。
Superpowers卡死「怎么做、按什么流程做」，是执行护栏，但它不定义需求标准。多人协作时，每个人就算都守纪律，也可能按自己的理解写，最后还是对不上。二者搭配，才形成一个完整闭环：一个防需求跑偏，一个防执行走样。

第3层：多Agent编排与治理层

代表工具是Paperclip管理平台。到这一层解决的已经不是编码问题了，是组织管理问题。

当你从一个Agent干所有事，演进到架构师、编码、测试、审核分角色协作，同时管好几个项目的时候，就需要一个控制平面：

任务怎么分发、状态怎么追踪、预算怎么管控、权限怎么隔离、出了问题怎么审计回放。
这些都是治理层面的事，和写代码本身没关系。

相关问题：

**Q：**Paperclip是不是比下层的工具更高级？做选型的时候，什么时候该上编排层？

Paperclip是管理平台，不是执行工具，和下层工具没有高低之分。它解决的是组织管理问题，不是编码问题，本身并不替代底层执行链路。

判断要不要上编排层，主要看三个条件：

同时跑3个以上项目、需要多角色Agent分工、有统一的预算/权限/审计需求。
满足两个以上再考虑，否则平台治理成本很可能高于收益。
有些团队一共两个人两个项目，也要搭编排平台，最后维护平台的工作量比写业务还多，这类场景就不划算。

2.2 四类常用标准组合

分层是理论，落地到具体项目，社区和行业已经踩坑踩出了四类标准组合。

每一种都对应一类典型场景，也是面试场景题的核心出题点。

不光要知道组合是什么，还要讲清为什么这么搭、解决了什么痛点、有什么边界、踩过什么坑。

组合方案	构成与角色分工	适用重心	收益更像来自哪里	主要代价
基础效率组合	Claude Code（执行软件）+ Hermes（运行时框架）	单人长期开发	少讲重复上下文，经验能沉淀下来	缺少工程纪律，质量靠个人兜底
规范交付组合	Claude Code（执行软件）+ SpecKit（规格工具包）+ Superpowers（纪律插件）	企业级交付、强合规项目	需求和执行都被锁住，返工扯皮会明显减少	流程更重，Token和沟通成本会上来
折中平衡组合	Claude Code（执行软件）+ Hermes（运行时框架）+ Superpowers（纪律插件）	中型项目、小团队协作	既保住个人效率，也把测试、评审底线兜住	没有统一规格，团队变大后容易需求对不齐
平台治理组合	Paperclip（管理平台）+ 下层任意执行组合	多项目多团队、平台化运营	项目、预算、权限、审计能统一放到台面上管	部署和运维最重，小团队用起来容易降效

这些收益不要理解成实验室里的精确指标，更像团队复盘时会用的粗算口径。

真正选型时，一般会把成本拆成四类：Token成本、部署成本、维护成本、返工成本。

很多人只盯着前两项，最后往往省了工具钱，花了更多人肉对齐和返工时间。

组合一：基础效率组合 —— Claude Code + Hermes

这个组合最适合一个人长期维护项目。

Claude Code负责真正写代码、跑命令、修报错，Hermes负责把项目背景、个人习惯和历史经验攒下来。简单说，Claude Code干活，Hermes记账和攒经验。

它解决的不是“能不能写代码”，而是“下次能不能少重复解释”。原生Claude Code每次新开会话都偏无状态，同一个项目的目录结构、编码习惯、历史坑点，经常要反复讲。Hermes加进来以后，核心记忆、历史会话和可复用技能会在会话启动时被带进上下文，开发者还是正常提需求，但Agent不用每次从零理解项目。

这套组合在个人项目里很舒服。维护开源小工具、写自动化运维脚本、做私人开发工具、单人快速迭代产品，都很合适。它轻，启动成本低，长期越用越顺手。

但它也有两个坑。

第一个坑是记忆膨胀。我们维护过一个爬虫类项目，一开始觉得“多记一点总没坏处”，把站点规则、异常日志、临时修复记录都往记忆文件里塞。两三个月后，旧规则和新规则混在一起，Agent有时会把已经废弃的处理逻辑又拿出来用，排查起来比不用记忆还麻烦。后来我们改成每月清一次核心记忆，只保留项目结构、长期约定和稳定经验，临时问题放会话检索里，才稳定下来。

第二个坑是拿它去做团队协作。6个人一起做电商后台，却每个人各自用一套Hermes记忆，短期看都很快，联调时才发现接口定义、异常码、测试标准各搞一套，最后光对齐接口就花了一周。后来补了轻量Spec模板，把核心接口先定住，问题才收敛。

所以这个组合的边界很清楚：适合个人长期提效，不适合多人强交付。面试里如果被追问“最大短板是什么”，就说它缺工程约束，AI跳测试、省评审、乱写代码都靠模型自觉。个人自己兜底没问题，对外交付或强合规项目至少要加Superpowers守住TDD和评审底线。

如果追问“长期怎么避免记忆越来越乱”，重点不是调参，而是治理：核心记忆要遵守硬上限，过时、重复的信息定期删；会话记忆要归档，临时对话不要永久污染主记忆；技能库要合并同类项，过时技能及时下线。记忆系统越长期，越要靠减法维持稳定。

组合二：规范交付组合 —— Claude Code + SpecKit + Superpowers

这套组合是给企业级交付准备的，尤其适合金融、政企、核心系统改造这类场景。

它的逻辑很朴素：需求先锁住，执行再卡住，最后由Claude Code落地。

SpecKit定“做成什么样”，Superpowers卡“按什么流程做”，Claude Code负责“具体怎么改代码”。

三者合起来，才形成“需求-执行-校验”的闭环。

AI开发里最容易出问题的两个点，一个是需求漂移，一个是执行失控。

只上SpecKit，规格写得再好，AI执行的时候偷工减料、跳测试，交付质量还是不稳；
只上Superpowers，纪律是有了，但多人协作没有统一需求标准，最后还是各理解各的。

落地时，一般先通过SpecKit生成标准化spec文档，校验通过后，再让加载了Superpowers技能的Claude Code基于spec开发。

开发过程中，TDD、调试、评审这些动作会被持续触发
每一步输出都要和spec对齐，不符合就回退。

这样做最大的好处不是“流程看起来规范”，而是出了问题能追：哪条需求、哪段实现、哪次校验出了偏差，链路是能拉出来看的。

不过这套组合也不是越满越好。有的小伙伴，一上来就全量SpecKit，小功能也写完整规格文档，结果一个原本半天能改完的后台字段调整，被规格、计划、任务拆分拖成了一天半。后来复盘发现，不是SpecKit不好，是把它用错了场景。

现在更稳的做法是分级：

核心模块、公共接口、影响面大的改动，用全量spec；
边缘模块、内部工具、小功能迭代，用轻量模板；
单行bug修复、临时小调整，只保留变更说明和测试记录，靠Superpowers守质量底线。

这样既保留追溯性，也不会把小任务做成大项目。

所以它适合企业级核心系统、金融/政企交付、多人协作复杂项目、遗留系统重构、强合规系统；不适合单人小项目、快速原型验证、一次性临时需求。

面试里如果问“企业级项目为什么SpecKit和Superpowers要一起上”，不要只说“一个管需求，一个管执行”。要把风险讲透：企业级交付要的是确定性，不是“可能做好”。只锁需求不锁执行，AI会在落地环节打折；只锁执行不锁需求，大家会按不同理解做同一件事。所以需求锁和执行锁一道都不能少。

组合三：折中平衡组合 —— Claude Code + Hermes + Superpowers

这个组合很适合3到5人的小团队，也是很多内部系统、个人商业化项目最容易落地的一档配置。

它的取舍很清楚：Claude Code做执行底座，Hermes保长期记忆和自动化效率，Superpowers守TDD、评审、自测这些质量底线。暂时不全量上SpecKit，是因为小团队沟通半径还短，需求可以先靠口头对齐和轻量文档承接，没必要一开始就把规格流程铺满。

为什么是保Superpowers、暂缓SpecKit，而不是反过来？因为上线质量底线不能省。测试、评审、自测这些动作没了，代码很容易变成“能跑但不稳”。SpecKit解决的是需求对齐和文档完备性，小团队在早期不一定非要全量上。说白了，先保底线，再补规格。

落地上也比较顺。

Hermes的Skill系统如果兼容Agent Skills，Superpowers技能文件就可以直接导入技能目录，相当于给灵活的Hermes装上一层纪律护栏。开发者仍然享受Hermes的记忆和自动化，但关键步骤不会完全放任Agent自由发挥。

这套方案的边界在团队变大之后会暴露。我们之前有个项目从3个人涨到8个人，还一直用这套组合，没有上SpecKit。前期大家坐得近，口头一对就能改；后面模块拆开、角色变多，需求变更开始靠聊天记录流转，谁都觉得自己理解对了，最后验收时才发现口径不一致。那次返工比补规格还贵。

所以它适合中型项目、3到5人小团队、快速迭代的内部系统、个人商业化项目，以及“想保质量但不想上重型规范”的场景；不适合大型多人协作、强合规交付、需求复杂易变的项目。

如果面试官问“后面团队扩大了怎么升级”，不要说推倒重来。正确做法是分步叠加：先给核心模块、公共接口引入SpecKit轻量模板，把关键规格立住；团队继续扩大后，再推广到全项目，从轻量模板过渡到全量模板；项目多到管不过来，再上编排治理层。选型不是一锤子买卖，是跟团队规模一起长出来的。

组合四：平台治理组合 —— Paperclip + 下层任意执行链路

Paperclip这一层，只有在项目和Agent数量起来之后才有意义。它不是更强的编码工具，而是平台级控制面。

它在上层管组织、任务、预算、权限和审计；下层执行链路可以按项目类型自由搭。

内部工具、快速迭代项目可以走Hermes + Claude轻量流；交付类、核心系统可以走SpecKit + Superpowers + Claude规范流。上层统一治理，下层按需选择，不搞一刀切。

项目少的时候，人肉同步也能撑住。一旦同时跑五六个项目、十几个Agent，问题就会变得很具体：

没人知道每个项目花了多少Token，权限边界靠口头约定
出了问题找不到执行链路，任务进度全靠人工同步。

Paperclip要解决的就是这种规模化管理的混乱。

落地时，关键不是把所有项目都塞进同一条重型流水线，而是分层治理。

内部工具、快速迭代项目走轻量流水线；交付类、核心系统走规范流水线；平台只统一管预算、权限、任务状态和审计。

至于Hermes、Claude Code、SpecKit+Superpowers这些底层节点怎么接，要看团队现有适配能力和平台接口，不要为了平台化强行改掉所有团队的开发习惯。

这层最容易被滥用。见过一些团队为了显得技术先进，一共两个人两个项目，也要搭Paperclip平台。结果每周都要花时间清日志、调权限、看任务状态，真正写业务的时间反而被挤掉。后来把平台下掉，改成Claude Code + Hermes + Superpowers，交付节奏反而快了。

所以判断要不要上平台治理，核心不是“技术先进不先进”，而是治理收益是否大于平台成本。

可以看三个信号：

同时运行的项目超过5个，人工同步进度和统计成本已经明显上升；
Agent角色超过3种，需要分权限、分职责协作；有明确的预算管控、权限隔离、审计追溯要求。
满足其中两个，再考虑上平台。否则部署、配置、运维花的精力，很可能比省下来的管理成本还多。

面试里如果问“Paperclip能不能单独开发”，答案一定要明确：不能。它本身没有编码能力，只是调度和管理平台，必须搭配底层执行工具才能落地。把它当成更高级的编码Agent，是没有分清控制平面和执行引擎。

三、场景化选型决策方法

工具从来不是挑出来的，是顺着项目的约束一层层配出来的。约束越强，叠的层越多；约束越松，方案越轻。

尼恩提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考尼恩免费百度网盘免费pdf ，点赞收藏本文后，截图找尼恩获取

四、选型里最容易踩的坑

尼恩提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考尼恩免费百度网盘免费pdf ，点赞收藏本文后，截图找尼恩获取

五、面试高频题怎么答

下面这些题，基本覆盖了大厂和AI创业公司在Agent工程化选型上常问的几个角度。

回答时不要只报工具名，要把场景、边界、取舍、落地动作一起讲出来。面试官真正想听的，不是背结论，而是你是不是能把一套工具链放回项目里去判断。

TOP 1：说说你对Hermes、SpecKit、Superpowers、Paperclip这几个工具的理解，它们之间有什么区别？

这几个工具不是横向竞品，而是分属不同层级。

Hermes补的是单人运行时记忆和自动化，更像个人助理；
SpecKit管的是需求规格和单一事实源，更像施工图；
Superpowers管的是TDD、调试、评审这些执行纪律，更像质量门禁；
Paperclip管的是多Agent、多项目的调度、预算、权限和审计，更像平台管控台。

一般不会先说“谁更强”，而是先说“它们分别解决哪一层的问题”。

如果项目只是个人写代码，先看执行层和运行时层就够了；如果开始多人协作，就得补规格和纪律；如果项目多到需要统一治理，再考虑Paperclip。选型不是四选一，而是看项目缺哪层能力，再按需叠加。

TOP 2：SpecKit和Superpowers的核心区别是什么？为什么经常搭配在一起用？

SpecKit管的是“做什么、做到什么标准”，Superpowers管的是“怎么做、按什么流程做”。

前者先把需求钉住，后者再把执行卡住。少了SpecKit，团队容易各写各的；少了Superpowers，规范写得再漂亮，落地时也可能跳测试、漏校验。

所以它们经常一起用，是因为两者正好补的是两个不同漏洞。SpecKit防的是需求漂移，Superpowers防的是执行走样。

一个管边界，一个管过程，合起来才算完整闭环。只靠其中一个，项目总会在另一头出问题。

TOP 3：Hermes+Claude是不是当前最强的Agent开发组合？

不是。更准确的说法是：它在单人长期开发、自动化运维里很好用，但不能拿它去覆盖所有场景。

Hermes+Claude的优势是轻、快、顺手。

它补的是记忆、技能和自动化，适合一个人长期维护项目，尤其是那些会反复回头改的东西。但它的问题也很明显：缺少强制工程纪律，缺少多人协作的统一标准，也缺少审计和治理能力。

所以它不是“最强”，只是“在它擅长的那类场景里很合适”。

如果是企业交付、多人协作、强合规项目，还是得往上加SpecKit、Superpowers，甚至Paperclip。面试里我会先把这句话讲清楚：没有全场景最强，只有场景匹配。

TOP 4：为什么小项目不建议上全量SpecKit？有没有折中方案？

核心不是“能不能用”，而是值不值。

小项目需求简单、协作少、返工半径小，全量SpecKit的文档、Token和沟通成本，往往比它带来的收益还大。很多时候不是项目不专业，而是项目没复杂到需要那套重流程。

我一般会给一个分级答案：临时任务只用原生工具；中小型项目先上Superpowers守质量底线；核心接口、多人协作部分再用轻量Spec；真正的复杂交付和强合规项目，才上全量SpecKit。

这样回答的好处是，既承认SpecKit的价值，也不把它神化。工具不是越全越专业，先把最容易出问题的地方补上，才是更像做工程的人。

TOP 5：Paperclip和LangGraph这类编排框架有什么区别？

LangGraph更像代码级编排框架，适合开发者自己搭状态流、工作流和复杂分支，灵活度高，但很多治理能力要自己补。

Paperclip更像产品化控制平面，开箱就带任务、预算、权限和审计，适合团队直接拿来管多Agent、多项目。

所以二者不是替代关系，而是关注点不同。一个偏“怎么编排”，一个偏“怎么治理”。

如果你要深度定制，底层用LangGraph这类框架会更自由；如果你要的是快速落地和统一管理，Paperclip这种平台更省事。很多团队会两者一起用，底层灵活，上层统一。

TOP 6：企业级项目为什么不能只依赖Hermes？

企业级项目要的是可控、可追溯、可协作，而Hermes主要解决的是个人效率。这个定位不一样，决定了它不能单独扛企业交付。

Hermes擅长的是记忆、自动化和个人长期提效，但它没有单一事实源，没有强制工程纪律，也没有权限审计和多人协作机制。

单人用它，效率会很高；放到企业项目里，如果只靠它，最后很容易变成“每个人都有自己的记忆和做法”，看起来快，实际上很散。

真要落地，至少要补Superpowers把质量底线守住；如果还涉及多人协作和明确交付，再加SpecKit；项目多起来以后，再往上补治理层。企业级项目不是不能用Hermes，而是不能只用Hermes。

TOP 7：Agent工程化工具链选型的底层原则是什么？

我会直接收成三句话。

第一，先分层，不跨维度比强弱。不同层干不同的活，别把执行工具和治理平台放在一起比。

第二，看约束，不脱离场景谈优劣。合规、协作、周期、成本不一样，选型就不一样。

第三，按需叠加，不一开始就堆全套。先解决最痛的那层，再往上补，不要为了显得完整把项目做重。

这三句话能讲顺，基本就说明你不是在背工具，而是在做工程判断。

六、总结：三条选型原则

不管是面试答题，还是真实项目选型，守住这三条，基本不会出方向性错误。

6.1 原则一：先分层级，不跨维度比强弱

很多人选型上来就把所有工具放一块比功能、比热度，拿Hermes和Paperclip比谁厉害，拿SpecKit和Superpowers比谁好用，全是错位对比，结论从根上就错。正确的第一步永远是先划清层级：执行层、运行时层、规范纪律层、编排治理层。不同层级分工不同，根本没有“谁更强”的说法，只有职责差异。就像不会拿产品和开发比写代码，岗位不同，评判标准完全不一样。

面试里一开口就说“XX比XX好用”基本就露怯了，先讲层级定位，再谈场景适配，才是懂行的思路。