基于 FastAPI + PydanticAI 搭一套可扩展的 Agent 基建：Toolsets、MCP、Skills、Approval 一次打通

如果只是把大模型 API 调通，做一个“能聊天”的 Demo 并不难；真正难的是，当项目进入服务端落地阶段之后，如何把tools、MCP、skills、审批流、会话历史、流式响应这些能力组织成一套可扩展、可治理、可持续演进的工程骨架。这个项目就是围绕这个目标展开的：基于 FastAPI + PydanticAI，从 0 到 1 搭建一套面向服务端的 Agent 基建设施，并逐步打通 AgentRunner、FunctionToolsets、MCP动态装配、Skills 渐进式注入、Approval / Resume、SSE Stream 等关键链路。

1. 为什么不能停留在“聊天 Demo”
   • Demo 和工程化服务端的差异
   • AI 服务端真正需要解决的问题是什么
2. 这套项目基建解决了什么
   • Agent 注册与运行时装配
   • Toolsets 与工具治理
   • MCP 动态接入
   • Skills 渐进式注入
   • Approval / Resume / Streaming / Session History
3. 整体架构怎么设计
   • FastAPI app.state
   • init_ai_runtime
   • AgentRegistry
   • AgentManager
   • AgentRunner
   • ChatService
   • /chat、/chat/stream、/chat/resume
4. Toolsets 怎么做工程化治理
   • 为什么不用零散 @agent.tool
   • 为什么要 FunctionToolset
   • metadata、audit、approval wrapper 的意义
5. MCP 是怎么接入运行时的
   • AI_MCP_SERVERS_JSON
   • 请求级 mcp_servers
   • 自动 MCP 路由
   • 显式优先，自动兜底
6. Skills 怎么做渐进式注入
   • 为什么 skill 不是另一个 Agent
   • skill.yaml + SKILL.md
   • SkillLoader / SkillRegistry / SkillResolver
   • skill 与 toolsets / MCP 的依赖关系
7. Approval 与 Resume 的闭环怎么设计
   • 为什么不能直接执行高风险工具
   • DeferredToolRequests
   • /chat/resume 的角色
8. 如何扩展你自己的能力
   • 如何接入自己的 tools
   • 如何接入自己的 MCP
   • 如何新增自己的 skills
   • 如何新增自己的 agent
9. 当前阶段完成了什么，后面还会继续做什么
   • 已完成阶段
   • 后续阶段：Observability / Guardrails / 业务 Agent 落地
10. 项目地址与交流
    • GitHub 地址
    • github.com/ExileLine/e…