当我们谈论 AI Agent 的能力时，很容易把所有能力混为一谈。但 Solon AI 提出的 Talents（才能）和 Claude Code 定义的 Skills（技能），实际上代表了两种截然不同的能力获取模型。理解这个区别，直接影响你设计 Agent 的架构决策。
Skills：边做边学的实习生
Claude Code 的 Agent Skills 强调的是运行时学习。Agent 在执行任务的过程中，根据反馈和上下文，动态获得新的能力。就像一个实习生加入项目后，通过实际操作逐渐掌握了团队特有的调试流程、代码规范、部署脚本——这些不是入职前就有的，而是在项目中"学"来的。
Skills 的核心特征：
- 能力在运行时动态生成
- 依赖任务上下文和反馈循环
- 同一个 Agent 在不同项目中可能发展出不同的 Skills
这意味着 Agent 的能力集合是开放的、可变的。优点是灵活，缺点是不可预测——你很难在部署前断言"这个 Agent一定能做某件事"。
Talents：自带专业本领的工程师
Solon AI 的 Talents 则是开发时添加的内在能力。你在设计 Agent 的时候，就已经把某些能力写进了 Agent 的定义里。就像一位资深工程师入职前就精通分布式系统设计、性能调优、安全审计——这些能力不需要在项目中重新学习，它们是工程师本身的一部分。
Talents 的核心特征：
- 能力在开发阶段定义和注入
- 不依赖运行时学习，部署后直接可用
- Agent 的能力集合在部署时就已经确定
这种模型的优点是可控：你能明确知道 Agent 能做什么、不能做什么。缺点是扩展性受限——新增能力需要回到开发阶段重新定义。
设计渊源与分歧
Solon AI Talents 在设计上深度参考了 Claude Code Agent Skills 的概念原型，但选择了不同的实现路径。Skills 把"能力获取"交给运行时，追求灵活性和适应性；Talents 把"能力定义"交给开发者，追求可控性和确定性。这不是谁对谁错，而是两种不同的工程哲学。
打个比方：Skills 像 Git 的动态分支——随工作进展不断生长；Talents 像 Docker 镜像——构建时就把运行环境锁定了。前者适合探索，后者适合交付。
实践：如何定义和使用 Talents
下面用 Solon AI 的 Talent 定义示例，展示开发时注入能力的具体做法。
定义 Talent
// 在 Solon AI 中定义一个 Talent — 开发时即注入的能力
@SolonAI
public class CodeReviewAgent {
@Talent(name = "securityAudit",
desc = "检查代码中的安全漏洞：SQL注入、XSS、硬编码密钥等")
public String securityAudit(String code) {
Prompt prompt = Prompt.of("审查以下代码的安全风险，列出具体问题和修复建议：")
.add(code);
return aiModel.chat(prompt);
}
@Talent(name = "performanceCheck",
desc = "识别代码中的性能瓶颈：N+1查询、不必要的循环、内存泄漏风险")
public String performanceCheck(String code) {
Prompt prompt = Prompt.of("分析以下代码的性能问题，给出优化方案：")
.add(code);
return aiModel.chat(prompt);
}
}
这个 Agent 部署后，立刻就能做安全审计和性能检查——不需要先跑几个任务"学会"这些能力。
配置 Agent 与 Talent 的绑定
# solon-ai.yml — Agent 与 Talent 的配置关系
ai:
agents:
code-reviewer:
model: gpt-4
talents:
- securityAudit
- performanceCheck
system_prompt: |
你是一个代码审查助手。使用你内置的才能来分析代码。
当收到代码片段时，依次调用 securityAudit 和 performanceCheck。
修改 solon-ai.yml 中的 talents 列表，就能精确控制 Agent 出厂时具备哪些能力。
对比：如果用 Skills 模型
# Claude Code Skills 模型 — 运行时学习
# Agent 初始不具备代码审查能力，通过任务反馈逐渐习得
agent = ClaudeCodeAgent(model="claude-3")
# 第一次任务：Agent 还不会做安全审查，结果可能不理想
result = agent.run("审查这段代码的安全性", code_snippet)
# 通过反馈，Agent 学习了新 Skill
agent.learn_from_feedback(
task="代码安全审查",
feedback="需要检查SQL注入、XSS、硬编码密钥",
skill_name="security_review"
)
# 第二次任务：Agent 已经"学会"了安全审查，结果质量提升
result = agent.run("审查这段代码的安全性", another_snippet)
关键差异一目了然：Talents 在 @Talent 注解时就锁定了能力，Skills 在 learn_from_feedback 时才生长出来。
什么时候用哪种模型？
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 生产环境、合规要求高 | Talents | 能力确定、可审计、不依赖运行时变量 |
| 探索性任务、研究型项目 | Skills | Agent 可以根据发现动态扩展能力 |
| 团队协作、多人共用 Agent | Talents | 所有人获得一致的能力基线 |
| 长期运行、上下文丰富 | Skills | 随时间积累的上下文让学习更有效 |
两种模型也可以混合使用：用 Talents 提供稳定的基础能力底盘，用 Skills 让 Agent 在特定场景中持续进化。关键是在设计之初就想清楚——哪些能力必须是"出厂自带"的，哪些可以"边做边学"。这个决策，比选哪个框架更重要。