背景:为什么做投标情报 Agent
一家欧洲 B2B 服务公司的投标经理与定价分析师,约 70% 工时花在不需要判断力的行政工作上:文档审阅、截止日抽取、资质匹配、门户跟踪。瓶颈不是标书质量,而是「战略思考前的准备量」太大。
生产级多智能体价值的常态不是「AI 替代人」,而是「AI 清跑道,让人去做你真正付钱让他做的事」。本案例人头未变、产出翻倍——这是可复制范式,而非裁员叙事。
架构:4-Agent 流水线
四个职责单一的 Agent 串联成顺序流水线,每个只做一件事并产出结构化结果:
| Agent | 职责 | 输入 | 输出 |
|---|---|---|---|
| 抓取 Agent | 按节奏监控招标门户,按资质筛新机会 | 门户 URL、资质规则 | 候选机会清单 |
| 解析 Agent | PDF 规范/条款转结构化数据 | PDF 文档 | 结构化字段 |
| 抽取 Agent | 识别需求/截止日/资质/评分标准 | 解析结果 | 需求-能力匹配表 |
| 分析 Agent | 组装优先级简报,预匹配既有能力 | 抽取结果 | 投标团队优先简报 |
顺序流水线适合该场景(无复杂分支);若需「规划→合规打回→重改→发布」式回路,应改用显式状态管理的图编排(如 LangGraph)。
可复现部署步骤
- Week 1:梳理资质规则与门户清单,定义成功指标(提交量、合规准确率)先于编码
- Week 2:FastAPI 微服务骨架,PostgreSQL 存状态,Docker 容器化便于独立扩缩
- Week 3:实现抓取 Agent(加速率限制,避免被门户封禁)
- Week 4:实现解析 + 抽取 Agent(PDF → 结构化 → 需求匹配)
- Week 5:实现分析 Agent 简报输出,接入人工复核回路
- Week 6:灰度(部分门户),比对人工基准,校准阈值
- Week 7+:扩展门户覆盖,加可观测(逐 Agent 成功率/延迟看板)
技术栈与数据流转
| 层 | 选型 | 理由 |
|---|---|---|
| 编排 | 顺序流水线(可升级 LangGraph) | 顺序场景足够,降低协调税 |
| 服务 | FastAPI 微服务 | 每 Agent 独立扩缩 |
| 状态 | PostgreSQL | 结构化状态、审计友好 |
| 推理 | OpenAI via LangChain | 生态成熟、可控路由 |
| 部署 | Docker | 隔离、可复现 |
若接企业内系统(招标门户/CRM/知识库),用 MCP 服务器以只读方式接入,避免手写集成;OpenClaw / NemoClaw 可作自托管运行时,把数据留在内网。
量化 ROI
首六个月生产运行结果(人头未变):
| 指标 | 部署前 | 部署后 | 变化 |
|---|---|---|---|
| 提交量 | 基线 | — | +400% |
| 合规准确率 | 人工 | — | 接近 100% |
| 投标团队工时结构 | 70% 行政 | 转向定价/竞争分析 | 结构优化 |
| 人头 | 不变 | 不变 | 产出翻倍 |
价值不来自减人,而来自把高薪岗位的产能释放到判断性工作。可复制的同类模式:旅游营销内容自动化(LangGraph + Pinecone + 只读 MCP,产出 5–7→12–14 篇/日、座位填充 +14%、发布人力 −58%)。
五条避坑指南
- 先定指标再写代码:投标案例的成功因子是领域专家与工程师从第 1 天共定成功指标,控制平面以合规为首要约束而非事后补
- 从 2–3 个 Agent 起步:每加一个 Agent 复杂度倍增,5 Agent 链端到端可靠仅 77%;瓶颈明确再加
- 门户抓取加速率限制:无限制抓取会被封禁,速率限制是生产必需而非可选项
- 必配可观测:无分布式追踪,多智能体调试慢 3–5 倍;逐 Agent 成功率/延迟看板是运维底线
- MCP 只读接入内系统:招标门户/CRM 用只读 MCP 服务器,最小化权限,避免误写与数据泄露
版本与安全注意
| 维度 | 建议 | 理由 |
|---|---|---|
| 编排框架 | 顺序足够则用微服务;需回路用 LangGraph | 避免为简单流引入重协调税 |
| 运行时 | OpenClaw / NemoClaw 自托管 | 数据不出墙、审计轨迹 |
| 接入 | MCP 只读 + 最小权限 | 防误写、防泄露 |
| 合规 | EU AI Act 对齐(高风险提示) | 完整训练文档 + 实时监控 + 人工监督 |
若面向受监管行业(金融/医疗),优先 NemoClaw 企业级加固发行版叠加护栏,核心 Agent 仍可用 OpenClaw 原版;控制平面与审计日志独立存储,满足行业审计要求。