Agent 多场景自动化手记：让 Agent 在边界内自主

Agent 多场景自动化常被误解为“接上所有 API，让大模型自己规划”。其实，Agent 的价值不是替代流程，而是在明确边界内，把意图翻译成工具调用，把多场景收敛成可复用能力。

最初，很多人会这样写：

if scene == "客服":
    answer = agent.chat(user_input, tools=[查订单, 退换货])
elif scene == "运维":
    answer = agent.run(user_input, tools=[查日志, 重启服务])
elif scene == "报表":
    answer = agent.run(user_input, tools=[查数, 生成图表])

能跑，但场景一多，分支爆炸。权限、上下文、回退、审计全混在一起。Agent 成了 if-else 的壳，新增场景就要改主流程。

软件设计师看到的是变化方向：场景会变，工具会变，策略会变，但“理解意图—选择工具—执行—观察—回答”的循环相对稳定。于是把变化关进配置里：

SCENES = {
    "客服": Scene(tools=[查订单, 退换货], policy="只读+退款审批"),
    "运维": Scene(tools=[查日志, 重启服务], policy="重启二次确认"),
    "报表": Scene(tools=[查数, 生成图表], policy="只读"),
}

def run(scene, text):
    ctx = Context(scene, text)
    while not ctx.done:
        action = llm.decide(ctx)
        ctx.observe(execute(action, scene.policy))
    return ctx.answer

代码很少，难的是边界设计。多场景自动化的关键，不是让一个 Agent 什么都会，而是让每个场景只暴露必要的工具和权限。

第一，场景即边界。每个场景有独立工具集、记忆、权限和评估指标。客服不能重启服务，报表不能写数据库。边界清晰，Agent 才不会越权。

第二，工具即契约。工具描述要清楚，参数要可校验，执行要幂等，结果要可审计。工具不是 API 的裸包装，而是业务能力的稳定接口。

第三，策略即护栏。权限、审批、预算、超时、重试、人工兜底，都要在策略层定义。高风险动作必须二次确认，不能让模型直接决定。

第四，反馈即学习。每次轨迹、失败案例、人工修正，都应回流为评估集。没有评估的 Agent，只是随机自动化。

第五，人机协同。高确定性、低变化、强合规的场景，传统工作流更可靠。Agent 适合意图模糊、步骤多变、工具组合多的场景。不是所有流程都需要 Agent。

好的 Agent 多场景自动化，在代码里往往看不见。它不炫耀自主性，不堆砌工具，而是让每个场景只承担该承担的职责，让新增场景只加一份配置。真正的好设计，会在下一次业务变化时显现：别人忙着改主流程，你只需要加一个 Scene。