**流程应该有多标准化

1️⃣ 考察意图

面试官想考察你在 Agent 系统设计中，对标准化与灵活性这对核心矛盾的工程权衡能力。这不是背概念题，而是系统设计 + 工程取舍题。刁钻点在于：候选人往往只谈“要标准化”或“要灵活”，却答不出何时、如何、以什么代价做切换。答好了能展示你对 Agent 工作流的配置化抽象能力、对鲁棒性与可维护性的实战理解，以及面对复杂业务场景时不盲目堆 LLM的工程直觉。

2️⃣ 标准答

核心原则：标准化是保底，灵活性是上限。 标准化的程度取决于流程的确定性和失败代价。

1. 按流程确定性分档

高确定性流程（如工单处理、订单退款）：采用状态机（State Machine） 或 DAG（有向无环图）。每个步骤（输入验证→库存检查→支付处理→通知）是硬编码的节点，Agent 只负责节点内的参数填充。为什么这么做：这类流程失败代价高（如重复退款），LLM 的自由决策会引入不可控风险。状态机保证 100% 可回溯、可审计。
低确定性流程（如创意写作、头脑风暴）：采用单一 Prompt + 工具调用。Agent 自主决定调用哪些工具（搜索、画图、写代码）和顺序。工程取舍：牺牲可预测性换取创造力，但必须用护栏（Guardrails） 兜底（如禁止调用删除 API、输出长度限制）。
中等确定性流程（如客服问答）：混合模式。核心步骤（身份验证、敏感词过滤）强制标准化，回答生成阶段允许 LLM 自由发挥，但需遵循安全规则（如不承诺赔偿金额）。

2. 配置化机制：标准化程度的“旋钮”

外部规则引擎：用 YAML/JSON 定义流程模板，例如：

`steps:**- name: input_validation type: mandatory method: regex_check

name: response_generation type: optional method: llm_free guardrails: [no_pii, no_commitment] `运行时解析配置，动态决定哪些步骤强制、哪些可选。实际落地的坑**：配置变更需要热加载，否则每次改流程都要重启服务，线上事故频发。解法：用 etcd 或 Redis 做配置中心，监听变更后刷新内存中的流程定义。
Prompt 模板动态注入：标准化程度通过 Prompt 中的指令控制。例如，高标准化时 Prompt 包含“必须按以下步骤执行：1. 调用 verify_order API；2. 若返回 error，直接输出‘请联系客服’”；低标准化时 Prompt 只写“请用工具解决用户问题”。为什么这么做：避免为每个场景写死代码，用 Prompt 作为“软开关”降低维护成本。

3. 评估标准化对系统的影响

鲁棒性：高标准化降低 LLM 幻觉风险，但增加开发成本（每个流程都要写状态机）。trade-off：对于高频流程（如登录），标准化收益远大于成本；对于长尾流程（如个性化推荐），标准化会扼杀效果。
可维护性：配置化框架让非研发人员（如运营）能调整流程，但配置本身需要版本管理和灰度发布。实际落地的坑：配置错误导致生产事故（如漏掉安全步骤）。解法：配置 Schema 校验 + 单元测试，每次变更自动跑回归。

总结：标准化不是非黑即白，而是按业务场景、失败代价、开发资源动态调节的连续谱。核心工程能力是抽象出可配置的流程框架，让标准化程度像旋钮一样可调。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，按流程确定性分档——高确定性用状态机，低确定性用自由 Prompt，中等用混合模式；第二，通过配置化机制实现动态调节，比如外部规则引擎或 Prompt 模板注入；第三，评估标准化对鲁棒性和可维护性的影响，用配置校验和灰度发布兜底。总结一句：标准化是保底，灵活性是上限，核心是抽象出可配置的流程框架。”

4️⃣ 高频追问 & 应对

追问 1：你提到状态机，如果流程中途需要根据 LLM 输出动态分支怎么办？

状态机本身支持条件分支（如 if-else 节点），但分支逻辑必须硬编码。如果分支条件由 LLM 动态生成（如“根据用户情绪选择回复策略”），我会在状态机中嵌入一个 LLM 决策节点，该节点输出一个枚举值（如 emotion: angry/happy），然后状态机根据枚举值路由到不同子流程。工程取舍：LLM 决策节点会引入延迟和不确定性，所以我会限制其输出格式（用 JSON Schema 约束），并设置超时和重试。

追问 2：配置化框架如何保证不同标准化程度下的用户体验一致性？

关键在于统一输出规范。无论流程是状态机还是自由 Prompt，最终输出必须经过一个 Post-processing 层，该层做三件事：1. 格式标准化（如统一 Markdown 结构）；2. 安全过滤（如脱敏、禁止敏感词）；3. 质量兜底（如如果 LLM 输出为空，回退到模板回答）。实际落地的坑：Post-processing 层可能过度修正，破坏 LLM 的创意输出。解法：对低标准化流程，只做安全过滤，不做格式修正。

追问 3：如果业务方要求同一个流程在不同用户群体上标准化程度不同（如 VIP 用户更灵活），怎么设计？

在配置化框架中引入用户画像维度。流程模板定义时，每个步骤可以加一个 condition 字段，例如 condition: user.tier == 'vip'。运行时，根据用户画像动态解析条件，决定是否跳过或替换步骤。工程取舍：这增加了配置复杂度，需要设计清晰的 DSL（领域特定语言）来避免配置爆炸。我会限制条件只支持简单逻辑（如等于、包含），不支持复杂嵌套。

5️⃣ 避坑 · 常见错误答法

❌ “标准化越高越好，因为 LLM 不可控，全用状态机最安全。” → ✅ “标准化要按场景权衡：高频高失败代价流程用状态机，低频创意流程用自由 Prompt，否则开发成本爆炸且扼杀效果。”
❌ “灵活性越高越好，让 LLM 自由发挥，效果最好。” → ✅ “灵活性需要护栏兜底，否则 LLM 可能调用危险 API 或输出违规内容，必须用 Guardrails 和输出校验。”
❌ “用配置化框架一劳永逸，所有流程都能动态调整。” → ✅ “配置化框架有维护成本，配置变更需要版本管理和灰度发布，否则配置错误会导致生产事故。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“RAG 流程的标准化”切入，比如检索阶段用 BM25 标准化，生成阶段用 LLM 自由发挥，并展示你如何用配置化框架控制检索深度和生成温度。
如果你只做过传统 NLP：用“传统 NLP 的 pipeline 标准化”类比，比如分词→NER→分类是固定流程，而 Agent 流程类似但多了 LLM 决策节点，强调你如何用状态机迁移经验。
如果你是校招无项目：聚焦“论文复现 demo”，比如复现 ReAct 论文时，你发现固定步骤（思考→行动→观察）是标准化，但行动类型需要灵活性，于是用配置化 Prompt 控制行动列表。
《Building LLM Applications for Production》by Chip Huyen（第 4 章：Workflow Design）
《ReAct: Synergizing Reasoning and Acting in Language Models》（论文，理解 Agent 流程的标准化与灵活性）
《LangGraph: A Framework for Building Stateful, Multi-Agent Applications》（工具，状态机实现参考）
《Guardrails for LLM-based Systems: A Survey》（博客，理解护栏设计）
《Configuration Management Best Practices for Microservices》（博客，配置热加载和灰度发布）

—— 本场面试完 ——