# 构建内部AI代理：代码驱动与LLM驱动工作流的技术对比与工程权衡 > 深入分析构建内部AI代理时代码驱动与LLM驱动两种工作流的技术实现差异、适用场景选择标准，以及工程化决策框架。 ## 元数据 - 路径: /posts/2026/01/02/code-vs-llm-workflows-internal-agent/ - 发布时间: 2026-01-02T05:50:04+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在AI代理系统快速发展的今天，企业构建内部AI代理时面临一个关键架构决策：采用LLM驱动的工作流，还是回归传统的代码驱动模式？Will Larson在Imprint公司的实践经验揭示了这一决策背后的深层技术考量。本文将从技术实现、适用场景和工程权衡三个维度，系统分析两种工作流模式的差异，并提供可落地的决策框架。 ## 确定性需求：从理想主义到工程现实 Larson最初坚信"LLM+工具使用可以解决任意复杂工作流"，这一假设在许多场景下确实成立。他构建的Slack PR合并检测工作流就是一个典型例子：通过LLM分析Slack频道中的消息，提取GitHub PR链接，检查状态，并为已合并的PR添加`:merged:`表情。从概念上看，这个工作流完美无缺——智能的工具使用，优雅的自动化。 然而，现实很快给出了不同的答案。系统有时会错误地为未合并的PR添加`:merged:`表情，导致团队成员无法依赖这个信号来判断哪些PR需要关注。正如Larson所言："它实际上没有解决我试图解决的问题：错误添加reacji意味着人们无法根据reacji的存在来评估是否查看某个拉取请求。" 这个案例揭示了LLM驱动工作流的核心挑战：**非确定性**。即使是最先进的LLM，在处理需要100%准确性的任务时，仍然可能产生不可预测的偏差。这种偏差在简单的PR状态检测中可能只是小问题，但在财务计算、安全审计或合规检查等场景中，可能带来严重后果。 ## 技术架构对比：共享基础设施，不同控制模式 ### LLM驱动工作流架构 LLM驱动工作流通过一个软件处理器（handler）协调，其工作流程如下： 1. **触发识别**：外部事件触发工作流，处理器匹配对应的配置 2. **资源准备**：加载关联的提示词、批准的工具列表，生成虚拟文件（如Jira附件、Slack消息文件） 3. **LLM协调**：将提示词和可用工具发送给LLM，协调工具调用，管理虚拟文件访问 4. **终止控制**：设置工具使用限制，防止无限循环或过度调用 5. **结果处理**：根据配置决定是否将LLM的最终响应输出到目标系统（如Slack） 配置示例： ```yaml # 默认行为（可省略） coordinator: llm ``` ### 代码驱动工作流架构 代码驱动工作流采用相同的触发机制和资源访问层，但控制权转移到自定义代码： ```yaml coordinator: script coordinator_script: scripts/pr_merged.py ``` 关键设计要点： - **相同权限模型**：Python脚本拥有与LLM相同的工具访问权限、触发数据和虚拟文件访问能力 - **按需LLM调用**：代码可以通过`subagent`工具在需要时调用LLM，实现混合控制 - **工程化流程**：脚本作为常规代码提交，经过代码审查、测试和版本控制 ### 架构共性设计 两种模式共享的核心基础设施包括： - **工具抽象层**：统一的工具注册、授权和调用接口 - **虚拟文件系统**：跨平台文件访问抽象（Slack附件、Jira问题文件等） - **触发机制**：统一的事件监听和路由系统 - **配置管理**：中心化的工作流配置存储 这种共享设计确保了两种模式可以无缝切换，也为渐进式迁移提供了技术基础。 ## 适用场景分析：何时选择哪种工作流 ### 优先选择LLM驱动工作流的场景 1. **探索性任务**：需求不明确，需要AI协助探索解决方案空间 2. **自然语言处理**：文本分析、情感识别、内容摘要等LLM原生优势领域 3. **创意生成**：文档起草、代码构思、设计建议等创造性工作 4. **低风险决策**：错误成本可接受的非关键业务逻辑 5. **快速原型**：需要快速验证概念，时间紧迫的场景 Larson团队的经验是："我们仍然从LLM开始所有工作流，这在许多情况下都有效。" ### 优先选择代码驱动工作流的场景 1. **确定性要求高**：财务计算、状态检测、合规检查等需要100%准确性的任务 2. **性能敏感**：需要低延迟、高吞吐量的生产工作流 3. **复杂业务逻辑**：涉及多系统集成、状态管理和错误处理的复杂流程 4. **长期维护**：需要稳定运行、可测试、可调试的生产系统 5. **成本控制**：避免不必要的LLM调用，降低运营成本 ### 混合模式的最佳实践 最有效的策略往往是混合使用两种模式： - **LLM作为入口**：用LLM处理自然语言输入，解析意图，然后路由到专门的代码模块 - **代码控制流程**：用代码管理工作流状态、错误处理和系统集成 - **LLM处理异常**：在代码无法处理的边缘情况下，调用LLM进行智能决策 - **渐进式迁移**：从LLM驱动开始，随着需求明确和可靠性要求提高，逐步迁移到代码驱动 ## 工程化决策框架 ### 决策矩阵：四个关键维度 基于Larson的实践，我们提出以下决策框架： | 维度 | LLM驱动优势 | 代码驱动优势 | 决策阈值 | |------|-------------|-------------|----------| | **确定性** | 低（70-95%） | 高（>99.9%） | 当准确性要求>95%时选择代码驱动 | | **开发速度** | 快（小时级） | 慢（天级） | 原型阶段用LLM，生产阶段评估迁移 | | **维护成本** | 高（提示工程、模型更新） | 中（代码维护、测试） | 长期运行的工作流倾向代码驱动 | | **灵活性** | 高（适应新场景） | 低（需要代码修改） | 需求频繁变化时保留LLM选项 | ### 技术选型检查清单 在构建内部AI代理时，使用以下检查清单指导技术决策： 1. **准确性要求评估** - 任务失败的业务影响是什么？ - 可接受的错误率是多少？ - 是否有验证和纠正机制？ 2. **性能需求分析** - 延迟要求（实时、近实时、批量）？ - 吞吐量需求（QPS、并发数）？ - 成本预算（LLM调用费用）？ 3. **维护性考量** - 工作流变更频率？ - 团队技能组合（提示工程 vs 软件开发）？ - 监控和调试需求？ 4. **演进路径规划** - 是否需要从LLM驱动迁移到代码驱动？ - 架构是否支持渐进式迁移？ - 是否有回滚机制？ ### 实施路线图 基于Larson团队的实践经验，推荐以下实施路径： **阶段1：LLM优先探索** - 所有新工作流从LLM驱动开始 - 建立统一的工具抽象和配置管理 - 收集性能、准确性和可靠性数据 **阶段2：识别迁移候选** - 监控工作流的错误率和业务影响 - 识别高价值、高可靠性的候选工作流 - 评估迁移到代码驱动的成本和收益 **阶段3：渐进式迁移** - 使用Claude Code等工具将提示词转换为代码 - 保持向后兼容性，支持两种模式并行运行 - 逐步将流量从LLM迁移到代码版本 **阶段4：混合架构优化** - 建立代码驱动工作流的标准模板 - 优化LLM调用模式（批量、缓存、降级） - 完善监控、告警和自愈机制 ## 技术实现细节与最佳实践 ### 配置管理策略 Larson团队采用的配置模式提供了良好的灵活性： ```yaml # 工作流基础配置 workflow: name: "pr_merge_notification" trigger: "slack_message" trigger_pattern: ".*github.com.*pull.*" # 模式选择 coordinator: "script" # 或 "llm" # LLM模式配置 llm_config: model: "claude-3-5-sonnet" temperature: 0.1 max_tokens: 1000 # 代码模式配置 script_config: path: "scripts/pr_merged.py" timeout: 30 retry_policy: "exponential_backoff" # 共享工具配置 tools: - "github_api" - "slack_client" - "jira_integration" ``` ### 错误处理与监控 无论选择哪种模式，都需要建立完善的错误处理机制： 1. **LLM驱动工作流的错误处理** - 设置工具调用次数限制 - 实现超时控制和重试逻辑 - 建立LLM输出验证层 - 记录完整的思维链用于调试 2. **代码驱动工作流的错误处理** - 结构化异常处理 - 事务性操作支持 - 状态持久化和恢复 - 详细的日志和指标收集 3. **统一监控体系** - 成功率、延迟、成本指标 - 业务影响度量（如错误决策导致的损失） - 容量规划和自动扩缩容 - A/B测试和渐进式发布支持 ### 团队协作与技能发展 构建混合架构的AI代理系统需要跨职能团队协作： 1. **提示工程师**：专注于LLM提示优化、few-shot学习、思维链设计 2. **软件工程师**：负责代码驱动工作流的开发、测试和部署 3. **ML工程师**：管理模型选择、微调、评估和更新 4. **运维工程师**：确保系统可靠性、监控和故障排除 团队应该建立共享的知识库，包括： - 提示词模板库和最佳实践 - 代码工作流的标准模式和工具 - 性能基准和成本分析 - 故障案例和解决方案 ## 未来展望与演进趋势 随着AI技术的快速发展，代码驱动与LLM驱动工作流的边界正在变得模糊。几个值得关注的趋势： 1. **AI辅助代码生成成熟化**：如Claude Code已经能够"几乎总是将提示词重写为代码工作流"，这降低了从LLM迁移到代码的门槛。 2. **确定性LLM的兴起**：通过约束解码、程序引导生成等技术，LLM正在获得更强的确定性保证。 3. **混合推理架构**：结合符号推理、规则引擎和神经网络的混合系统，在保持灵活性的同时提高可靠性。 4. **自主演进系统**：能够根据性能数据自动在LLM驱动和代码驱动之间切换的自适应系统。 Larson的结论具有启发性："即使模型变得更强大，在真正需要智能的地方依赖它们，而不是用于迭代工作流，似乎是我们工具包中的长期补充。" ## 结语 构建内部AI代理时，代码驱动与LLM驱动工作流不是非此即彼的选择，而是互补的工具。成功的架构应该支持两种模式，并根据具体场景的需求动态选择。 关键洞察包括： - **从LLM开始**：利用其快速原型和探索能力 - **为确定性而迁移**：当可靠性要求超过LLM能力时，迁移到代码驱动 - **保持架构灵活性**：设计支持两种模式的基础设施 - **建立数据驱动的决策流程**：基于性能指标而非直觉做出技术选择 最终，最有效的AI代理系统将是那些能够智能地在人类编写的代码和AI生成的推理之间找到平衡点的系统。这种平衡不是静态的，而是随着技术发展、业务需求变化和团队经验积累而不断演进的动态过程。 --- **资料来源**： 1. Will Larson, "Building an internal agent: Code-driven vs LLM-driven workflows", Irrational Exuberance, 2025-12-31 2. Hacker News讨论："Building an internal agent: Code-driven vs. LLM-driven workflows", 2026-01-01 ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。