> 原创文章，来源于 AI 技术趋势自动整理。发布前请在腾讯云开发者社区编辑器中复核标题、封面、标签和外链。

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法

## 1. Lyft 用 LangGraph、LangSmith 搭建客服自助 Agent 平台：从工单分流到可观测编排

Lyft 近日披露了其客户支持场景中的自助式 AI Agent 平台建设思路。这个案例的核心不是“用大模型替代客服”，而是把乘客、司机常见问题中的查询、判断、补偿、状态同步等动作，拆成可编排、可观测、可回滚的工作流，再通过 LangGraph 和 LangSmith 管理 Agent 的执行路径与质量表现。

应用场景集中在客服自助处理：例如订单状态查询、行程异常解释、账户问题引导、退款或补偿流程前置判断。过去这些请求往往依赖人工坐席读取多个后台系统，再按规则回复。Lyft 的目标是让 Agent 能在权限边界内调用内部 API，完成信息收集、意图识别、规则判断和回复生成，减少简单工单进入人工队列。

接入前提并不轻。团队需要先具备稳定的业务 API、清晰的身份权限模型、可审计的数据访问策略，以及能区分“可自动处理”和“必须人工介入”的客服规则。LangGraph 在这里承担任务编排角色，把一次对话拆成多个节点，例如识别问题、拉取订单、校验用户身份、调用政策规则、生成答复、触发人工升级。LangSmith 则用于记录链路、追踪调用、评估回复质量和定位失败节点。

最小可行架构可以很克制：一个前端客服入口，一个 Agent 服务层，一个 LangGraph 状态机，少量内部 API 工具，以及 LangSmith 观测面板。落地架构再逐步扩展到多 Agent 协作、策略规则服务、权限网关、灰度发布、人工审核台和离线评测集。真正的技术落地点，是把客服流程从“自由对话”改造成“受控工作流”，而不是让模型自由决定所有动作。

<ol><li>梳理高频工单，优先选择规则清晰、风险较低的场景，如订单查询、状态解释、资料补全。</li><li>把业务动作封装为工具或 API，例如用户认证、行程检索、补偿规则查询、工单创建。</li><li>用 LangGraph 定义状态流转，明确每个节点的输入、输出、失败分支和人工升级条件。</li><li>通过 LangSmith 记录提示词、工具调用、延迟、失败率、人工接管率和用户反馈。</li><li>采用灰度部署，先覆盖内部客服助手或低风险自助入口，再扩大到真实用户。</li></ol>

部署方式上，这类平台更适合以独立 Agent 服务运行，接入现有客服系统和内部网关。环境变量、密钥管理、服务账号权限、日志脱敏必须提前处理；涉及乘客行程、支付、身份信息时，Agent 不应直接暴露原始敏感字段，而应通过后端服务返回最小必要结果。

风险同样明确。复杂指令、多轮上下文丢失、工具调用超时、API 返回冲突都会影响客服体验；LangSmith 能帮助定位问题，但不能替代业务评测。更现实的限制是：人类审核成本不会消失，只是从“逐单处理”转向“设计规则、复核边界案例、维护评测集”。短期看，这类方案更适合已有客服系统、API 基础和工程团队的平台型公司；不适合业务规则混乱、数据权限未梳理、只想快速接一个聊天机器人的团队。

可复用建议是先做窄场景闭环，不要一开始追求全能客服。把 Agent 当作可观测的业务执行层，围绕命中率、转人工率、工具失败率、平均响应时延和用户满意度迭代。Lyft 的经验说明，LangGraph 和 LangSmith 的价值在于把 Agent 从演示样例推进到可调试、可评估、可上线的工程系统。

关键词：客服、编排、观测、权限、API

## 2. Codex 进入税务审核链路：Tax AI 如何把人工修错变成系统自改进

OpenAI Devs 披露的 Tax AI 项目，核心不是“用 AI 报税”这么简单，而是把 Codex 接进税务准备和复核流程：当审核人员发现错误并修正后，系统能够追踪失败来源，生成改进方案，并在测试通过后再进入发布流程。这个场景很典型，税务处理有大量规则、表格、例外条款和人工复核动作，单纯靠聊天式助手很难稳定交付，真正的价值在于把人类 reviewer 的修改沉淀成可验证的系统改进。

应用场景主要集中在税务预处理、资料归类、申报表草稿生成、异常项解释、复核意见回写等环节。Thrive Holdings 与 OpenAI 共同构建的 Tax AI，更像一个面向专业服务流程的 Agent 工程样板：不是让模型直接替代税务专家，而是让 Codex 在错误发生后参与“定位原因、修改逻辑、补测试、等待发布”的闭环。短期真正适合的是已有标准化审核流程、能积累错误样本、并且有工程团队维护规则和测试集的税务、审计、财务服务团队；不适合流程还靠口头经验、数据权限混乱的小团队直接照搬。

接入前提很现实：企业需要有结构化的税务工作流、可追踪的 reviewer 操作记录、版本化的规则或代码仓库，以及一套能跑回归测试的数据集。最小可行架构可以从四层开始：业务系统负责收集客户材料和表格；Agent 编排层负责调用 LLM、规则引擎和工具；Codex 或类似代码 Agent 负责分析失败并提交修改建议；CI 测试层负责跑单元测试、历史案例回放和差异检查。这里的关键不是模型多强，而是每一次修错都能留下“输入、输出、人工修改、失败标签、关联规则、测试结果”。

落地架构可以进一步拆成数据流：客户资料进入文档解析与字段抽取模块，经由 RAG 检索税法条款、内部作业规范和历史案例；Agent 生成税务处理建议或表格草稿；人工 reviewer 在工作台中修改错误并打标签；错误样本进入失败分析队列；Codex 根据日志、规则文件、测试失败信息生成补丁；补丁进入 Git 分支和 CI；测试通过后由人类批准合并。这条链路里，人工审核不是被绕开，而是被产品化成训练和改进信号。

<ol><li>先选一个低风险流程，例如资料分类或异常项解释，不要一开始碰最终申报提交。</li><li>建立错误 taxonomy，例如字段抽取错、规则适用错、解释缺失、格式不合规。</li><li>把 reviewer 的修改动作结构化记录，避免只留下自由文本批注。</li><li>为高频错误补回归测试，用历史案例验证修改是否引入新问题。</li><li>将 Codex 生成的改动限制在规则、提示词、校验器或测试文件范围内，生产代码合并必须走审批。</li></ol>

部署方式上，税务类 Agent 通常更适合私有云、VPC 或混合部署。敏感材料可以留在企业侧，模型调用只传脱敏字段；向量库保存税法条款、内部 SOP 和案例摘要；审计日志需要记录每次工具调用、模型输入输出、人工覆盖动作和最终版本。可观测指标不应只看“自动化率”，还要看 reviewer 修改率、同类错误复发率、补丁回滚率、测试覆盖率、平均复核时长。

风险也很明确。税务规则存在地区差异和时效性，RAG 检索到旧条款、工具调用失败、字段脱敏过度、Codex 修改范围失控，都会造成隐蔽错误。更麻烦的是评估成本：很多税务判断没有简单的标准答案，需要资深 reviewer 参与标注和验收，人类审核成本不会消失，只会从“逐条处理”转移到“设计边界、验收改动、处理例外”。可复用的经验是，把 Agent 当成受控的流程改进器，而不是自主报税员；先让它学会解释失败，再让它提出修改，最后才考虑扩大自动执行范围。

关键词：Codex、税务、审核、RAG、Agent

## 3. ITBench-AA发布：开源Agent在企业IT任务中仍难跨过50分

IBM Research在Hugging Face发布的ITBench-AA，把Agent评测从通用问答拉回到更硬的企业IT场景：读文档、查系统状态、调用工具、定位故障、执行变更。这个基准给出的信号并不轻松，当前排名靠前的开源Agent在企业IT任务上的综合得分仍不到50%。这说明Agent已经能进入IT运维、服务台、配置排查、自动化巡检等流程，但距离无人值守处理复杂系统问题还有明显距离。

ITBench-AA解决的是一个老问题：很多团队只看模型在代码、数学或聊天任务上的表现，却很少评估它能不能在真实IT环境里稳定完成任务。企业IT任务通常不是单轮问答，而是由CMDB、监控告警、日志平台、工单系统、Shell命令、云厂商API共同组成的链路。Agent需要理解上下文，还要知道什么时候调用工具、什么时候停止、什么时候把结果交给人审核。

接入这类Agent前，最低前提不是模型越强越好，而是系统边界清楚。团队至少要准备三类条件：<ul><li>可读数据源，例如Runbook、故障手册、历史工单、监控指标和日志摘要；</li><li>可控工具接口，例如Kubernetes API、Ansible、ServiceNow、Jira、Prometheus或内部运维平台；</li><li>权限分层机制，把查询、诊断、变更、回滚拆成不同级别，避免Agent拿到过宽权限。</li></ul>

最小可行架构可以很简单：一个LLM推理层，一个任务编排器，一个工具调用层，加上RAG知识库和审计日志。用户提交“数据库连接异常”这类请求后，Agent先检索Runbook和历史工单，再读取监控指标与最近日志，生成诊断路径；如果需要执行命令，只允许调用白名单工具，并把高风险操作转为人工确认。真正的技术落地点在工具调用和权限边界，而不是把聊天机器人接到IT群里。

更完整的落地架构通常会加入评测与观测层。ITBench-AA的价值就在这里：它把任务拆成可评分流程，帮助团队观察Agent是否能完成目标、是否误用工具、是否产生无效步骤、是否在错误状态下继续执行。实际项目里可以把这些指标扩展为任务成功率、工具调用成功率、平均处理步数、人工接管率、回滚次数和单次任务成本。

实施路径建议分四步走：<ol><li>选取低风险场景，例如告警解释、工单分类、日志摘要和Runbook推荐；</li><li>建立离线评测集，用历史工单复现输入、工具返回和期望结果；</li><li>接入只读工具，先验证Agent能否稳定完成诊断；</li><li>再逐步开放半自动操作，例如重启非核心服务、生成变更单、执行预检查脚本。</li></ol>

部署方式上，小团队可以先用API模型加容器化编排，把工具层放在内网网关后面；对安全要求更高的团队，可以采用私有化模型或本地推理，把日志、工单和配置数据留在内网。无论哪种方式，都要保留完整审计链路，包括提示词版本、检索内容、工具入参、返回结果和最终动作。

限制也很明确。企业IT环境里，工具调用失败、权限不足、返回格式变化、日志噪声和过期Runbook都会放大Agent错误。评测集如果只覆盖“标准答案”，上线后很快会被边缘故障击穿。短期看，ITBench-AA更适合有成熟运维流程、已有Runbook和监控体系的技术团队做选型与灰度验证；不适合流程混乱、权限边界不清、连基础告警都未标准化的团队直接追求自动化闭环。

可复用的经验是，把Agent当作“带工具的诊断执行器”，而不是全能运维替身。先让它读得准、查得全、解释得清，再考虑让它动手。ITBench-AA低于50%的结果反而给了一个现实坐标：企业IT Agent的竞争不只在模型能力，也在任务拆解、工具契约、权限治理和持续评测。

关键词：Agent、评测、运维、工具链、权限

## 4. Microsoft Foundry 模型路由器评估：把质量、成本和延迟放进同一条流水线

Microsoft 5月19日在 Foundry 开发者博客发布的模型路由器评估实践，关注的是一个越来越常见的 Agent 工程问题：同一个任务到底该交给 GPT-4.1、GPT-4o mini、Phi 系列，还是其他专用模型。模型路由器不是简单的负载均衡，它更像 Agent 系统里的调度层，需要在质量、成本和延迟之间做取舍。对于客服 Agent、代码助手、知识库问答、内部审批流这类高频调用场景，路由策略一旦选错，要么账单失控，要么响应变慢，要么复杂问题被便宜模型误判。

原文提到的开源 GitHub 存储库，核心价值在于把评估从“人工试几个 prompt”推进到可复现流程。接入前提并不复杂：团队需要准备一组真实或脱敏后的任务样本、候选模型列表、统一调用接口，以及能记录输出、价格、token、延迟和评分结果的评估环境。如果已经使用 Azure AI Foundry、GitHub Actions 或 OpenAI 兼容 API，最小可行架构可以先做成三层：请求样本集、模型路由器、评估记录表。路由器根据任务类型、上下文长度、风险等级选择模型，评估器再对返回结果打分。

更接近生产的落地架构会多一层观测和回放能力。数据流通常是：用户请求进入 Agent 编排层，路由器读取任务标签、预算阈值和 SLA，选择模型后发起调用；结果返回后进入业务校验、人工审核或自动评分模块；指标写入日志系统，例如 Prometheus、Application Insights 或自建数据库。真正要评估的不是某个模型“聪不聪明”，而是路由策略在特定业务分布下是否稳定。

<ol><li>整理评估集，覆盖简单问答、长上下文、多轮推理、工具调用失败、拒答边界等样本。</li><li>配置候选模型和价格参数，至少记录输入 token、输出 token、首 token 延迟和总耗时。</li><li>定义质量指标，可采用人工评分、规则校验、LLM-as-judge，或把三者组合使用。</li><li>运行基线策略，例如固定使用高端模型，再对比成本优先、延迟优先、质量优先三种路由策略。</li><li>把评估结果接入 CI，在 prompt、路由规则或模型版本变更时自动回归。</li></ol>

部署方式上，小团队可以先用本地脚本加 GitHub Actions 跑离线评估；已有云环境的团队可以把路由服务封装成 API，部署在 Azure Container Apps、Kubernetes 或普通函数服务中。关键是保留请求快照和模型版本号，否则线上问题回放会变成猜谜。这里有两个具体事实值得注意：Microsoft 原文场景来自 Foundry 生态，评估目标明确覆盖 quality、cost、latency；GitHub 存储库承担的是评估管道模板角色，而不是直接替业务决定最佳模型。

风险也很现实。评估集如果只来自演示样例，路由器上线后很容易在真实长尾问题上翻车；LLM-as-judge 会引入评审模型偏差，尤其在安全、合规、医疗、金融等场景不能替代人工抽检。短期看，这套方法更适合已经有稳定 Agent 调用量、并且开始关心成本曲线的开发团队；不适合还没有明确任务分布、每天请求量很低的原型项目。

可复用建议是把路由评估当成产品能力维护，而不是一次性压测。每次新增模型、修改 prompt、调整工具调用链，都应触发小规模回归；线上再按比例灰度，把失败样本回流到评估集。模型路由的落地点不在“自动选择最强模型”，而在用数据证明什么时候可以安全地用更便宜、更快的模型完成任务。

关键词：模型路由、评估、延迟、成本、Foundry

## 5. Foundry Local 1.1把转录、嵌入和响应接口推进本地 Agent 开发链路

Microsoft 在 Foundry Local 1.1 中加入实时转录、嵌入、Responses API、WebGPU 插件和下载取消能力，这次更新的重点不只是补齐模型调用接口，而是把本地 AI 应用常见的几段链路放到同一个开发环境里：语音输入、语义检索、模型响应、前端加速和资源管理。对做 Agent 原型的团队来说，Foundry Local 的价值在于降低云端依赖，尤其适合需要在开发机、边缘设备或内网环境里验证工作流的场景。

它解决的问题很具体。过去一个语音助手或客服 Agent 往往要分别接入转录服务、向量模型、LLM API 和前端推理插件，链路长、权限散、调试成本高。1.1 版本把实时转录和嵌入能力放进本地流程后，开发者可以更快搭出“用户说话—转文字—生成向量—检索上下文—调用 Responses API 回复”的最小可行架构。这里的技术落点是 SDK/API 接入和本地 RAG，而不是单纯跑一个模型。

接入前提包括 Foundry Local 运行环境、可用模型下载、应用侧对 Responses API 的适配，以及浏览器或桌面端是否能使用 WebGPU。WebGPU 插件更适合需要在客户端承担部分推理或渲染压力的应用，例如会议纪要、低延迟语音助手、知识库问答和本地代码助手。下载取消功能看似小，但在模型文件较大、网络不稳定或 CI 环境自动拉取模型时很实用，可以减少卡死和无效带宽占用。

<ol><li>先选定一个低风险场景，例如内部文档问答或实时会议摘要。</li><li>用实时转录接收语音输入，保存原始文本和时间戳。</li><li>通过嵌入接口把文本切片写入向量索引，检索结果作为上下文。</li><li>由 Responses API 统一处理提示词、上下文和回复格式。</li><li>把日志、延迟、命中率和人工修订记录接入观测面板。</li></ol>

更完整的落地架构通常会把 Foundry Local 放在开发机、本地服务器或边缘节点上，前端通过 WebGPU 做部分加速，后端保留权限控制、向量库、审计日志和任务编排模块。数据流可以设计为：客户端采集音频，本地转录服务生成文本，嵌入模型写入向量库，Agent 编排层决定是否调用工具、检索知识库或请求人工确认，最终由响应接口返回结果。对隐私敏感行业，本地部署还能减少原始语音和内部文档外传。

短期看，这件事更适合已经在做 Agent 原型、希望减少云 API 依赖的小团队和开发者，不适合还没有明确数据流、权限边界和评测口径的组织直接大规模铺开。限制也很明显：本地推理能力受硬件、模型体积和驱动环境影响，实时转录的准确率还要按口音、噪声、术语表单独评估；工具调用失败、检索误召回和人类审核成本不会因为接口本地化而消失。

可复用建议是把 Foundry Local 1.1 当成 Agent 工程底座的一层，而不是完整产品。接口层保持 OpenAI 风格或内部统一协议，向量库和编排器不要和某个模型强绑定；评测指标至少覆盖转录延迟、嵌入耗时、检索命中率、回答可接受率和人工回退比例。这样做的好处是，后续无论换模型、换部署位置，还是把部分能力迁到云端，都不需要重写整条 Agent 工作流。

关键词：本地、转录、嵌入、RAG、部署


原创文章，来源于 AI 技术趋势自动整理。发布前请在腾讯云开发者社区编辑器中复核标题、封面、标签和外链。

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法 1. Lyft 用 LangGraph、LangSmith 搭建客服自助 Agent 平台：从工单分流到可观测编排 Lyft 近日披露了其客户支持场景中的自助式 AI Agent 平台建设思路。这个案例的核心不是“用大模型替代客服”，而是把乘客、司机常见问题中的查询、判断、

人工智能

职业发展

新闻资讯

Lyft利用LangGraph和LangSmith构建客服自助Agent平台，通过工作流编排和信息调用提升效率。TaxAI项目将Codex集成到税务审核流程，实现错误追踪和系统自改进。ITBench-AA评测显示开源Agent在企业IT任务中仍有提升空间。Microsoft Foundry模型路由器评估关注质量、成本和延迟的平衡。Foundry Local 1.1更新助力本地Agent开发，集成语音转录、嵌入和响应接口，优化本地RAG和部署流程。

聊天机器人

语音助手

负载均衡

Kubernetes

数据库

私有云

数据流

路由器

服务器

容器

路由

2026采购季 | AI焕新·智启新局

腾讯云BI新客户首次购买9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Lyft利用LangGraph和LangSmith构建客服自助Agent平台，通过工作流编排和信息调用提升效率。TaxAI项目将Codex集成到税务审核流程，实现错误追踪和系统自改进。ITBench-AA评测显示开源Agent在企业IT任务中仍有提升空间。Microsoft Foundry模型路由器评估关注质量、成本和...

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法-腾讯云开发者社区-腾讯云

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法

5/28/2026 AI速递 | 开发者笔记：Codex与LangGraph实战用法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐