Python 智能体实战：从 0 搭建模块化 Agent 路由系统，落地小龙虾门店运营助手
给你一个可复现的最小版本：技能拆分、动态工具路由、API 封装、排错与上线建议一次讲清
如果你想做一个不只是会聊天，而是会根据任务自动选工具的 AI Agent，这篇可以直接开工。本文的目标很明确：
- 用 Python 搭一个模块化 skill-based agent；
- 让它支持动态工具路由；
- 把它落到一个实体行业场景：小龙虾门店运营助手。
最终产出不是 PPT，而是一个最小可运行接口：你发一句"给我一条今天午市外卖拉新的文案"，系统会先判断该走哪个 skill，再返回结果。先别急着造"全能钢铁侠"，工程上更靠谱的做法，往往是先把技能表写得像菜单一样清楚。
工具资源导航
如果你看完这波热点，想顺手把方案跑起来或者把账号环境补齐，这两个入口可以先收藏：
文末资源导航属于工具信息整理，请结合平台规则和自身需求判断。
一、先看热点：这波 Agent 新闻到底透露了什么
事实描述
- 2026-05-05 ，MarkTechPost 发布教程，主题是用 Python 构建模块化、基于技能的 LLM Agent 系统 ，核心点是 dynamic tool routing。
- 2026-05-05 ，TechCrunch 报道 CopilotKit 融资 2700 万美元 ，方向是帮助开发者部署 app-native AI agents。
- 2026-05-05 ，TechCrunch 报道 SAP 计划收购德国 AI 初创公司 Prior Labs 并重投，同时对客户 Agent 的可用范围采取更谨慎、有限开放的态度。
- 2026-05-06 ，Inworld AI 发布 Realtime TTS-2，强调语音模型基于完整音频上下文而不只是文本转写。
- 2026-05-06，Scientific American 讨论"AI agents 能否替代人类员工"，并提到已有创业公司拿这个问题做测试。
- 2026-05-06 ，世界经济论坛讨论了 agentic AI 可能如何改变"创始人"这个角色的工作方式。
观点分析
这些信息放在一起，指向的不是"聊天机器人 2.0"，而是三个更工程化的共识：
- Agent 正从单体走向模块化：能力要拆成 skill，不然维护会越来越像面条代码。
- Agent 正从演示走向应用内集成：CopilotKit 的融资说明，大家要的不是一个漂浮的 AI 入口，而是能嵌进业务流程的 agent。
- 企业落地会更看重治理：SAP 的谨慎态度说明，真正上线时，权限、白名单、审计日志比"模型多聪明"更先被问到。
二、场景定义：为什么我建议先做"小龙虾门店运营助手"
CSDN 读者很多都在找"能不能拿来做副业项目"的切口。与其做一个泛泛的 AI 助手，不如做一个垂直场景的小工具。
这里我们定义一个最小场景：
目标用户 ：餐饮门店老板或运营人员
常见任务：
- 回答顾客常见问题：营业时间、口味、配送范围
- 生成促销文案：午市拉新、社群通知、外卖活动
- 给出简单运营建议：备货、套餐、转化优化
也就是说，我们只做 3 个 skill：
faqpromo_copysales_analysis
这就是模块化的第一步：先缩问题，再做路由。
三、技术栈与最小闭环
为了可复现，我建议先用下面这套最小组合：
- Python 3.11
- FastAPI：暴露接口
- requests：调用兼容聊天补全风格的模型接口
- 一个可用的大模型 API：只负责"路由判断"
安装命令：
bash
pip install fastapi uvicorn pydantic requests
环境变量：
bash
export BASE_URL='你的模型接口基址'
export API_KEY='你的密钥'
export MODEL='你的模型名'
四、步骤拆解：从 skill 到动态路由
第 1 步：先写技能，不要先写"大脑"
很多人一上来就想让模型自动完成一切，结果最后谁都能干一点，谁都干不稳定。正确姿势是：先定义技能边界。
python
import os
import json
import requests
from fastapi import FastAPI
from pydantic import BaseModel
def faq(q: str) -> str:
return '门店营业到凌晨 2 点，支持微辣、中辣，外卖可下单。'
def promo_copy(q: str) -> str:
if '外卖' in q:
return '文案：今天午市小龙虾双人餐限时加赠冰饮，适合拼单，外卖下单更省心。'
return '文案：今晚到店点小龙虾套餐，可享限时加菜福利，适合朋友聚餐。'
def sales_analysis(q: str) -> str:
return '建议：优先看午市套餐转化、外卖占比和复购表现。当前示例未直连 POS，所以返回的是运营策略，不直接生成真实报表。'
SKILLS = {
'faq': {
'desc': '回答营业时间、口味、配送、门店基础信息',
'func': faq,
},
'promo_copy': {
'desc': '生成促销文案、社群通知、活动标题',
'func': promo_copy,
},
'sales_analysis': {
'desc': '分析销量、套餐、备货和简单运营建议',
'func': sales_analysis,
},
}
第 2 步：让模型只做"选路"，别让它包打天下
这里的大模型只负责一件事：在多个 skill 里选一个最合适的。
python
def fallback_route(user_text: str) -> dict:
if any(k in user_text for k in ['营业', '几点', '口味', '配送']):
return {'skill': 'faq', 'reason': '关键词命中 FAQ'}
if any(k in user_text for k in ['文案', '活动', '拉新', '社群', '外卖']):
return {'skill': 'promo_copy', 'reason': '关键词命中营销文案'}
if any(k in user_text for k in ['销量', '备货', '库存', '套餐', '转化']):
return {'skill': 'sales_analysis', 'reason': '关键词命中运营分析'}
return {'skill': 'faq', 'reason': '兜底路由'}
def route_by_llm(user_text: str) -> dict:
skill_text = '\n'.join([f"- {k}: {v['desc']}" for k, v in SKILLS.items()])
prompt = (
'你是一个工具路由器，只能从候选技能中选择 1 个，并严格返回 JSON。\n'
f'候选技能：\n{skill_text}\n'
f'用户问题：{user_text}\n'
'输出格式：{"skill":"技能名","reason":"简短原因"}'
)
try:
resp = requests.post(
os.environ['BASE_URL'].rstrip('/') + '/chat/completions',
headers={
'Authorization': f"Bearer {os.environ['API_KEY']}",
'Content-Type': 'application/json',
},
json={
'model': os.environ['MODEL'],
'messages': [{'role': 'user', 'content': prompt}],
'temperature': 0,
},
timeout=30,
)
content = resp.json()['choices'][0]['message']['content']
data = json.loads(content)
if data['skill'] in SKILLS:
return data
except Exception:
pass
return fallback_route(user_text)第 3 步：封装成 API，变成真正可调用的服务
python
app = FastAPI()
class AskReq(BaseModel):
question: str
@app.post('/ask')
def ask(req: AskReq):
route = route_by_llm(req.question)
result = SKILLS[route['skill']]'func'
return {
'route': route,
'result': result,
}
启动：
bash
uvicorn app:app --reload --port 8000
测试：
bash
curl -X POST 'http://127.0.0.1:8000/ask'
-H 'Content-Type: application/json'
-d '{"question":"给我一条今天午市外卖拉新的文案"}'
一个可能的返回结果：
{
"route": {
"skill": "promo_copy",
"reason": "用户要促销文案"
},
"result": "文案：今天午市小龙虾双人餐限时加赠冰饮，适合拼单，外卖下单更省心。"
}
到这里，你已经有了一个可复现的最小 Agent 闭环：输入问题 → 路由 → 调技能 → 返回结果。
五、调试排错：最常见的坑基本都在这里
1）模型不返回 JSON
解决方法：
- 路由提示词里明确"只能返回 JSON"
temperature=0- 加
fallback_route()兜底
2）路由不稳定，今天选文案，明天选 FAQ
原因通常不是模型太笨，而是skill 描述写得太模糊 。desc 要避免重叠，例如"处理用户问题"这种描述基本等于没写。
3）运营分析胡说八道
如果没接真实 POS、CRM、库存系统，就不要让它装作知道真实销量。上面的 sales_analysis() 故意只给策略性建议，这是事实边界，也是产品边界。
4）响应变慢
路由本身就是一次模型调用。如果你的场景请求量大，可以做两件事：
- 高频问题先走关键词路由
- 只有复杂问题才调用模型路由
六、上线建议：别急着全自动，先做"可控自动化"
结合 2026-05-05 TechCrunch 关于 SAP 的报道，我的建议很明确：企业环境里，Agent 首先要可治理，其次才是可炫技。
建议按这个顺序上线：
- 内部试运行：先给店长和运营同学用
- 白名单技能：只开放 FAQ、文案、基础建议，不要一开始就接支付、退款、真实库存改写
- 保留人工确认：活动文案、备货建议先让人点确认
- 记录日志：至少保留问题、路由结果、技能输出、耗时
如果你后面要做语音入口，2026-05-06 Inworld AI 发布 Realtime TTS-2 这条新闻也值得参考：语音 Agent 的体验关键不只是"能说话"，而是能持续理解上下文。所以别把语音版理解成"给文本套个喇叭"，那样很容易做成会说话的复读机。
七、成本与合规注意点
成本
- 用模型做"路由"而不是整段重写，通常比全量生成更省 token
- skill 描述尽量短，不要每次塞一大段背景材料
- 高频 FAQ 尽量缓存
合规
- 不要把用户手机号、详细订单、支付信息原样塞进提示词
- 对"备货建议""员工排班"这类可能影响经营决策的内容，加人工审核
- 给用户明确提示：这是 AI 辅助，不是最终经营结论
Scientific American 在 2026-05-06 讨论"AI agents 能否替代人类员工"，这个问题很抓眼球，但对开发者更有价值的角度是：先替代重复流程，再增强人工判断。否则你很容易得到一个看上去很聪明、出了事谁都不敢担责的系统。
八、趋势判断：开发者和副业实践者接下来该怎么做
事实描述
- MarkTechPost 的教程说明，模块化技能 + 动态路由已经是可操作的工程路径。
- CopilotKit 融资说明，市场在押注"应用内 Agent"，不是孤立聊天框。
- WEF 讨论 founder 被 agentic AI 改写，说明 AI 正在改变工作分工，而不只是增加一个工具栏按钮。
观点分析
如果你是开发者，下一阶段更值得做的，不是"再做一个通用助手"，而是：
- 做垂直场景 agent：餐饮、教育、招聘、客服、销售支持
- 做技能层：路由、记忆、评测、日志、权限
- 做应用内集成：嵌进 CRM、工单、内容后台，而不是停留在 demo 页
如果你想做副业项目，我更建议从"可付费的小功能"切入，例如：
- 门店 FAQ + 活动文案助手
- 社群运营回复助手
- 简单数据分析 + 建议输出助手
先让一个小 skill 稳定赚钱，再考虑扩展成多 skill agent。别一开始就想做全行业超级智能体，那通常是把复杂度和云账单一起点满。
结尾
这几条 2026 年 5 月初的 Agent 热点，放在一起看，其实结论很朴素：Agent 的下一步不是更会聊天，而是更会分工、更能接工具、更容易治理。
今天这套 Python 最小实现，已经足够你做出一个能演示、能测试、能继续扩展的原型。下一步你可以做三件事：
- 把 mock skill 换成真实业务数据源；
- 给路由结果加评测集，持续优化命中率；
- 逐步从文本入口扩展到语音或应用内嵌。
先把一个场景跑通，比讨论"AI 会不会取代所有人"更有生产力。工程世界里，能上线的系统，永远比会上发言更诚实。