n8n实操：Claude多agent采购谈判，超额度自动转Slack人工审批

原文要点

该n8n模板把采购审批做成多agent流程：webhook或手动收到采购请求后，Claude规划agent生成寻源方案，谈判agent对每个供应商模拟多轮还价直至达成一致、放弃或达到最大轮数，验证agent加代码级硬性校验（预算、交期、最低供应商评分）把关，报价upsert进Postgres；审批agent给出自动通过/升级/拒绝建议但硬护栏由代码强制执行。需升级时向Slack发带Approve/Reject链接的请求，等人点击经resume webhook恢复流程，最终决定写入procurement_decisions并回发Slack。

这次做成什么

在自有n8n上搭通这条采购多agent链路：配好Claude、Postgres、Slack三样凭据，建表，发一笔合成采购请求，分别验证“自动通过”和“超额度升级Slack人工审批”两条路径。练习数据为本站虚构。

准备什么

• 可导入并激活工作流的n8n实例
• Anthropic API key（模板用HTTP Header Auth的x-api-key方式）
• 可用的Postgres数据库及建表权限
• Slack工作区凭据和一个已存在的审批通知频道
• 能发POST的测试工具（curl/Postman），或用手动触发代替

具体怎么做

1. 导入模板并配置三种凭据

   导入n8n.io/workflows/20121。新建Anthropic凭据（x-api-key头）、Postgres凭据、Slack OAuth2凭据，分别绑定到对应节点；确认n8n能访问Anthropic Messages API。

2. 建库表

   在Postgres中创建procurement_offers与procurement_decisions两张表。原文未给出建表SQL，字段需对照模板里Postgres节点的列映射逐一建立；下方artifacts给出本站推测的起始结构，仅供起手，务必以模板实际写入字段为准。

3. 调整采购策略参数

   在procurement config节点设置auto-approve限额、最大谈判轮数、最低供应商评分、最大风险分和Slack频道名。练习建议：把auto-approve限额设为10000元，方便分别触发两条路径。

4. 发起小额请求验证自动通过

   激活工作流后向procurement-request的webhook地址POST下方示例载荷（金额低于限额），观察规划→逐供应商谈判→验证→写库→自动通过→Slack通知的完整执行。

5. 发起大额请求验证人工升级

   把请求金额调到限额之上重发，确认流程在Slack发出含Approve/Reject链接的消息后暂停等待；在Slack点Approve，确认resume webhook恢复执行，最终decision写入procurement_decisions且Slack收到结果通知。

可直接复制的材料

{
  "request_id": "PR-2026-0042",
  "item": "办公椅（人体工学款）",
  "quantity": 50,
  "budget_total": 9500,
  "currency": "CNY",
  "required_delivery_days": 21,
  "suppliers": [
    { "name": "恒信家具（虚构）", "unit_price": 198, "lead_time_days": 14, "rating": 4.6 },
    { "name": "优座供应链（虚构）", "unit_price": 172, "lead_time_days": 25, "rating": 4.1 },
    { "name": "华东办公家具厂（虚构）", "unit_price": 165, "lead_time_days": 10, "rating": 3.8 }
  ]
}

CREATE TABLE IF NOT EXISTS procurement_offers (
  id SERIAL PRIMARY KEY,
  request_id TEXT NOT NULL,
  supplier_name TEXT NOT NULL,
  unit_price NUMERIC(10,2),
  lead_time_days INT,
  rating NUMERIC(2,1),
  status TEXT,
  rounds INT,
  updated_at TIMESTAMP DEFAULT now(),
  UNIQUE (request_id, supplier_name)
);

CREATE TABLE IF NOT EXISTS procurement_decisions (
  id SERIAL PRIMARY KEY,
  request_id TEXT NOT NULL,
  decision TEXT,
  reason TEXT,
  approved_by TEXT,
  decided_at TIMESTAMP DEFAULT now()
);

输入与输出示例

本站虚构演示，谈判轮次与让步幅度为示意，非真实Claude输出。

输入

POST PR-2026-0042：50把办公椅、预算9500元、要求21天交付，三家虚构供应商报价198/172/165元，auto-approve限额10000元

对应输出

谈判后恒信让步到单价185元（总价9250，14天交付，评分4.6，通过硬性校验）；优座交期25天被硬性校验拦下；华东评分3.8低于最低评分被拒。审批agent建议auto-approve且代码护栏确认9250<10000，decision=auto_approved写入procurement_decisions，Slack频道收到“PR-2026-0042 已自动批准：恒信家具，9250元”通知。

做完检查这些

• 小额请求无需人工干预即完成：Postgres中每个供应商有一行offer记录，decisions表出现auto_approved记录
• 超限额请求在Slack出现含Approve/Reject链接的消息，且流程处于等待状态，未点击前库中无最终decision
• 点击Approve后流程恢复，decisions表写入approved并记录审批人；点Reject则写入rejected
• 违反硬护栏（如交期超要求或评分不足）的报价即使谈判价最低也不会中选

容易卡住的地方

• Anthropic凭据必须用x-api-key的Header Auth形式，配错类型会导致所有agent节点失败
• 两张Postgres表名必须与模板引用完全一致，列缺失会在upsert时报错
• Slack审批链接依赖点击者浏览器能访问n8n的resume webhook地址，自托管仅监听localhost会导致链接打不开
• 审批agent的建议只是建议，真正放行由代码护栏决定，调参时两类规则都要改
• 谈判轮数设太低可能全部walk-away导致无合格报价