函数调用 vs 明确指令：何时让 Agent 自主，何时强约束

许多团队在把 LLM 接入 n8n 时，都会在「多变现实 vs. 稳定交付」之间拉扯：要不要让 Agent 自行探索？又如何把风险、成本与合规压住？工程上，一味放开或一味收紧都会碰壁，关键在于明确边界、可观测与可回滚。

是什么：两种控制范式与中间地带

自治模式（Goal-seeking）：给定目标与工具权限，Agent 自行规划与迭代；适合开放探索、信息不完备、路径不确定的场景。

• 优点：覆盖面广，能在未知空间里试错收敛。
• 风险：费用不确定、越权操作、不可重复性。

约束模式（Policy-driven）：以规则、模板与预设流程为主，Agent 只在护栏内填空或选择；适合高一致性、强 SLA 与强合规。

• 优点：稳定、可审计、成本可控。
• 代价：对变化适应慢，易出现「卡死于边界」的问题。

护栏内自治（Hybrid）：先以策略圈定空间，再让 Agent 在圈内自主规划；以评测与回退机制保证结果。

为什么：边界、价值与风险的平衡

• 业务价值：开放问题（如竞品洞察）更适合自治；强流程（如报销审核）更适合约束。
• 组织成熟度：有 SRE/数据治理/灰度体系的团队，更能驾驭自治；否则先从约束起步。
• 可观测与回滚：凡是不可观测的自治，等于「黑箱押注」。必须先把日志、轨迹与撤销通路打通。

怎么做：在 n8n 的工程落地

总体思路：先建「策略-工具-评测」三层，再以工作流编排联通人机与外部系统。

1. 策略层（Policy）：把角色、权限、预算、重试与停机条件写成结构化变量（JSON/环境变量）。
2. 工具层（Tools）：只暴露最小可用集合（HTTP 请求、数据库、搜索、文档读取等），并加参数白名单与节流。
3. 评测层（Evaluator）：对每轮行动输出「证据、评分、信心、成本」四元组，超阈值才允许提交。
4. 人机联动：在关键节点设置「人工确认」分支，超时自动走安全默认值。
5. 可观测：为每一步打 traceId，汇总到日志/BI；异常走「补偿交易」或「反向调用」。

下面给出一个在 n8n 的最小原型骨架（以护栏内自治为例）。

// Function 节点：装载策略与上下文 const policy = { maxSteps: 8, budgetUSD: 0.8, allowTools: ["http:getSearch","db:read","docs:retrieve"], requireEvidence: true, stopOn: ["low_confidence","policy_violation"] }; return [{ json: { policy, goal: $json.goal, traceId: $json.traceId } }];

// Agent Planner（LLM）节点：生成下一步行动（受 policy 约束）
// 产物：{tool, params, rationale}

// IF 节点：工具白名单 + 预算控制 const { tool, params, cost } = $json.action; if (!policy.allowTools.includes(tool)) { return [{json:{error:"policy_violation", detail:"tool_not_allowed"}}]; } if (($json.costSoFar || 0) + cost > policy.budgetUSD) { return [{json:{error:"budget_exceeded"}}]; } return $input.all(); 

// HTTP Request / DB / Docs 节点：实际执行 // ……（各工具节点按需配置，参数取自 params） // Evaluator（LLM 或规则）节点：对证据打分 // 输出：{score, confidence, critique, costDelta} // IF 节点：低置信度则回到 Planner 重试（步数+1），或走人工确认 

落地清单（Rubric）：

• 所有外呼都记录 traceId、输入哈希与输出摘要；敏感字段脱敏。
• 每轮动作必须给出可验证「证据」：如 URL、文档片段、SQL 结果摘要。
• 成本与步数双阈值；越界则回退到上个安全快照。
• 关键操作（下单/转账/发信）前置人工确认或双人复核。

运行策略矩阵：

实战案例：把概念落到系统

案例 A・本地知识与外部检索融合（中型 B2B）

• 目标：生成销售线索简报并自动写入 CRM。
• 做法：n8n 拉取 CRM 与文件库摘要；Agent 先在内部库检索，再到外网补全；评测分低于 0.7 必须附三条证据。
• 结果：自治比例 ~60%，人工复核 ~40%，平均成本下降 35%，错配线索率下降 50%。

案例 B・电商客服半自动：以模板与规则优先，遇到异常（物流超时/高客诉）才启用自治补充背景；最终回复需命中语气与敏感词检查。

案例 C・采购比价流水线：先用规则对接触点去重与税率校验，再交给 Agent 在白名单源做补充检索；异常走工单。

如何扩展：从单体到「可演化系统」

• 评测集与离线回放：把历史任务做成基准集，离线跑新策略，达标再灰度。
• 多代理协作：启用「提案—反驳—合议」模式，限制对话轮次与投票规则。
• 知识与记忆：短期记忆入向量库，长期规范化入数据仓；对来源与时效打标签。
• Policy 即代码：把权限、速率、预算与停机条件集中配置与版本化，走审计流。
• 可观测与治理：统一追踪成本、时延、成功率与人工接管率，建立 SLO 与报警。

结语：一套可复用的选择框架

可借用的心法：先定边界与证据，再谈自治；先可观测与回滚，再扩搜索空间；把策略当代码，把评测做成常规 CI。

开放问题：在你的业务里，哪一类任务最适合从约束起步、再逐步放权？可以挑一条流程，在 n8n 里以「护栏内自治」试个最小闭环。

更多工程手记与模板，可关注 Dr.n8n（drn8n.com）。