2026 Agent 项目实战：从客服自动化到 8 小时研究任务，一套可复现的企业级多智能体搭建流程

2401_87632878

398人浏览 · 2026-06-20 17:17:25

2401_87632878 · 2026-06-20 17:17:25 发布

2026 Agent 项目实战：从客服自动化到 8 小时研究任务，一套可复现的企业级多智能体搭建流程

结合 Salesforce 收购 Fin、NewCore 身份体系和 Sakana Marlin 长任务能力，复盘一个可上线的 Agent Demo

做 Agent 项目时，最容易高估的是“模型会回答问题”，最容易低估的是“系统要为谁负责”。如果你这周就要交付一个能跑的企业级 Demo，我建议把目标压缩成两个可见产出：

一个能处理客服工单、检索知识库、生成回复建议的服务 Agent
一个能持续运行数小时、输出调研报告和汇报提纲的研究 Agent

我下面这套方案，最后能交付的是：FastAPI + 队列 Worker + 权限表 + 审计日志 + 模型降级 的最小闭环。它不花哨，但适合真正拿去试点，不会演示时一切顺利，上线后像周五晚上的 CI 一样突然红掉。

补充材料

如果需要继续查工具、账号或订阅资源，可以把下面信息当作补充材料：

工具网站：工具与 API 资源信息，可按站点说明了解服务和发票支持。
YT SuperStore：海外工具与订阅资源信息，适合做账号和服务选型参考。
ClaudeBuys：Claude Pro 充值与订阅服务信息，提供售后支持、便捷支付和发票支持，具体规则以站点说明为准。

文中工具入口属于资源信息整理，请结合平台规则和自身需求判断。

先把新闻拼成一个工程问题

2026 年 6 月 15 日，TechCrunch 报道 Salesforce 以 36 亿美元收购 AI 客服平台 Fin，官方表述是希望用 Fin 的团队和技术增强 Agentforce。这条消息很直接：企业级 Agent 已经不是“能不能做”，而是“谁能把客服这种高频场景做成稳定产品”。

同一天，TechCrunch 还提到 NewCore 获得 6600 万美元融资，核心方向是给 AI agents 建立身份。它给出的判断很有意思：企业安全接下来管理的对象，不只是人，还包括 AI agents。

再看 2026 年 6 月 15 日的 MarkTechPost：Sakana AI 把 AB-MCTS 商业化到 Sakana Marlin，能够连续运行最长 8 小时，输出最多 100 页研究报告和配套 slides。这个信号也很清楚，Agent 开始从“一次问答”走向“长任务执行”。

如果把这三条放到同一个项目板里，问题就不是“要不要接入大模型”，而是三件具体的事：

客服类 Agent 要不要进入正式工作流
每个 Agent 有没有独立身份、权限和审计记录
长任务失败时，系统怎么恢复，不要让一份周报跑到第二天还在转圈

场景定义：拿连锁家电售后服务中心做一个可落地案例

这里用一个实体行业案例：连锁家电售后服务中心。它比纯互联网业务更适合做 Agent 试点，因为问题标准化程度高，但又不会简单到只靠关键词匹配。

这个场景里可以拆出两个 Agent：

服务 Agent

输入：用户咨询、安装预约、保修条款、故障报码
动作：检索知识库、匹配服务政策、生成回复草稿、建议工单分类
输出：客服建议回复 + 是否转人工 + 工单标签

研究 Agent

输入：过去 7 天工单、投诉主题、地区差异、常见配件问题
动作：聚合数据、归纳趋势、生成周报提纲
输出：Markdown 报告、PPT 大纲、重点异常项

这不是新闻里已经落地的现成案例，而是基于上面三条新闻抽出的工程化做法。边界要分清：新闻提供的是行业信号，项目方案是我们对这些信号的实现路径。

技术栈：别急着上“全自动”，先把最小闭环跑通

在这里插入图片描述

我建议第一版用下面这套：

API 层：FastAPI
任务队列：Celery 或 RQ
缓存与队列：Redis
数据库：PostgreSQL
检索层：Postgres pgvector 或独立向量库
模型调用：统一封装 Provider Adapter，支持主模型与备用模型切换
审计：任务表、工具调用日志、人工接管日志

目录可以先长这样：

bash
agent-demo/
├── app/
│ ├── api/
│ ├── agents/
│ ├── providers/
│ ├── tools/
│ ├── models/
│ └── workers/
├── migrations/
├── scripts/
└── docker-compose.yml

启动命令先保持朴素：

bash
docker compose up -d postgres redis
uvicorn app.main:app --reload
celery -A app.workers.worker worker -l info

关键设计一：每个 Agent 先有身份，再谈能力

NewCore 那条新闻提醒得很及时。很多团队做 Demo 时，把 Agent 当“一个会调用工具的函数”。到权限收口那一步才发现，谁都能查工单、谁都能导出报表，风险比模型胡说还大。

一个简单可复现的做法，是给每个 Agent 建独立身份，并显式绑定工具权限：

python
AGENT_REGISTRY = {
“service_agent”: {
“scopes”: [“kb.read”, “ticket.read”, “ticket.comment”],
“max_runtime_sec”: 120,
},
“research_agent”: {
“scopes”: [“ticket.read”, “report.create”, “stats.read”],
“max_runtime_sec”: 28800,
}
}

def check_scope(agent_id: str, scope: str):
scopes = AGENT_REGISTRY[agent_id][“scopes”]
if scope not in scopes:
raise PermissionError(f"{agent_id} lacks {scope}")

注意这里不要偷懒复用“管理员 Token”。演示时省 10 分钟，上线后可能多出 10 个事故群。

关键设计二：长任务必须可中断、可续跑、可降级

在这里插入图片描述

Sakana Marlin 能跑最长 8 小时，这类能力很吸引人，但也顺手把系统设计难度抬高了。长任务 Agent 最怕三件事：模型不可用、上下文膨胀、步骤失控。

任务表至少要有这些字段：

sql
create table agent_tasks (
id uuid primary key,
agent_id text not null,
status text not null,
input jsonb not null,
output jsonb,
retry_count int default 0,
checkpoint jsonb,
created_at timestamp,
updated_at timestamp
);

Worker 执行时别一口气跑到底，最好按阶段打 checkpoint：

python
def run_research_task(task):
state = task.checkpoint or {}
data = collect_ticket_stats(task.input)
save_checkpoint(task.id, {“stage”: “collected”, “data”: data})

outline = generate_outline(data)
save_checkpoint(task.id, {"stage": "outlined", "outline": outline})

report = write_report(outline, data)
save_checkpoint(task.id, {"stage": "written", "report": report})

slides = build_slides_outline(report)
return {"report": report, "slides": slides}

这样模型在中途抽风，或者供应商侧出现可用性波动时，不至于整单重跑。2026 年 6 月 16 日还有一条 Google News 摘要提到 Anthropic 正在努力让最强模型重新上线，这种外部波动就提醒我们：模型切换不是锦上添花，是生产要求。