2025 年之前 Agent Engineering 更多思考的是如何跑通，而目前更多关注的是如何在商业化环境中稳定可靠地使用。
宏观趋势
从 2024 年到 2025 年的发展中，可以看出今年已经有更多的企业将 Agent 上线到生产环境中。
按企业规模看，大型企业的上线率通常更高：一方面其具备更成熟的平台工程与数据基础设施，另一方面在安全合规、风险控制与跨部门协同上资源更充足，因此更容易把 Agent 从“能跑”推进到“可控、可审计”的生产状态。
企业痛点
根据目前的调查，输出质量/输出延迟/安全合规是目前企业的主要痛点。
概率性与确定性
大模型的生成机制本质上是基于概率的序列预测：它倾向于给出“最可能”的下一个 token，而非对事实或业务规则作形式化证明。因此在生产环境中，哪怕整体表现不错，也仍可能出现偶发但高代价的失误——例如客服场景给出不存在的链接、前后口径不一致、或在边界条件下偏离品牌/合规话术。这类问题的核心不在于“模型是否聪明”，而在于输出的不确定性与业务对确定性的要求不匹配。
而从产品与工程设计角度，更可行的路径是把“概率性能力”嵌入一个可控系统：为高风险环节引入人机协作循环（Human-in-the-loop），并设计清晰的升级与降级策略。具体而言，应当预先定义哪些情形必须走人工审核或二次确认（例如涉及资金、隐私、写库、对外承诺、法律/医疗建议等），并把审核作为工作流的一部分而非临时补丁；当模型无法给出足够置信、证据不足或触发安全策略时，系统应“优雅降级”（例如转接人工、给出可解释的下一步、或仅输出可核验的引用与建议）。这种设计思路的目标不是完全消灭不确定性，而是把不确定性限制在可接受的业务边界内。
推理深度与实时性的权衡
提升输出质量通常意味着更深的推理链路与更多步骤，但这会直接带来更高的延迟与成本。在强交互场景（AI 客服、代码生成、实时协作）里，用户对等待时间的容忍度很有限。
从目前工程实践中最常用的方案是将系统设计为分层与路由：先以低成本、低延迟的路径满足多数“简单且明确”的请求；仅当任务复杂度超过阈值时，才升级到更强模型。具体落地可以采用“任务拆分 + 模型分流”的策略：由轻量模型处理意图识别、信息抽取、模板化回复、检索召回与工具参数准备；将复杂推理、长链规划或高精度生成交给更强模型完成，并配合流式输出/进度提示降低用户的等待焦虑。在体验、成本与质量之间形成可管理的平衡点。
安全与合规问题
企业在将 Agent 系统推向生产时，安全与合规往往不是“把模型放到内网”就能解决的单点问题，而是贯穿 输入 → 推理 → 工具调用 → 输出 → 日志与数据留存 的端到端治理。
常见的安全风险有如下三类：
- Prompt Injection → 工具滥用：攻击者通过输入诱导模型绕过指令、触发高权限工具调用，进而造成越权读写与数据外泄（OWASP LLM01、LLM08）
- 不安全输出处理 / 不安全插件设计：模型输出被下游系统当成可执行指令、SQL、脚本或 URL 直接消费，导致注入、RCE、SSRF 等传统安全问题以“LLM 输出”为载体重现
- 敏感信息泄露与过度依赖：模型可能在输出/日志中暴露隐私、商业机密或系统提示词；用户或业务系统过度信任输出会把“概率性答案”升级为“确定性决策”
通过构建工具权限矩阵和审计日志规范来合理约束问题。
观测与评估
无论是在传统机器模型应用，还是实际的推荐系统，都会涉及到对项目的持续监测和评估。前者是保证项目长期稳定可靠运行并在出现问题时定位问题的主要手段，后者直接影响输出质量从而决定用户体验。
Observability
目前在企业中，Agent Workflow 已经进入了精细化运营的阶段，从数据来看 89% 的组织已实现观测性，而在已投产的团队中，这一比例高达 94%。
同时 71.5% 的团队拥有完整的追踪能力，可以查看工作流中每一个推理步骤和工具调用的输出。
Evaluation
尽管大多数团队都有可靠的观测方法，但是如何在如何评判 Agent Workflow 设计好坏这一点上面仍然存在欠缺。
即使在生产环境中，仍有 22.8% 的团队没有进行系统评估。同时在评估方法上可以看出，内部人工评审（59.8%）仍是金标准，但 LLM-as-judge（53.3%）正迅速崛起以实现规模化评估。
Agent 的非确定性决定了 PM 必须亲自参与 “黄金测试集” 的构建。仅仅依靠技术手段无法定义什么是“好的回答”，PM 需要定义业务维度的 LLM-as-judge 准则。
模型选择
在当前阶段，大模型供给侧的竞争仍然高度激烈，企业端呈现出明显的多模型并用趋势：报告显示，超过三分之二的组织在其 Agent 体系中使用 OpenAI 的 GPT 系列模型，同时，Gemini、Claude 以及开源模型也获得了显著采用；更关键的是，超过四分之三的团队在生产或研发中会同时使用多个模型，并按任务复杂度、成本与延迟等因素进行路由与分层，而非押注单一供应商。这可以让公司有更大的议价空间和架构灵活性。
与此同时，微调并未成为主流的标准化路径。报告指出，多数组织选择以基础模型叠加 Prompt Engineering 与 RAG 等方式进行优化，约 57% 的组织不进行模型微调；原因在于微调往往意味着更高的数据采集与标注投入、训练与部署基础设施成本，以及后续持续维护的工程复杂度，因此更多被保留给高收益、强专用或强约束的场景。
问卷来源
本报告数据来自 LangChain 发起的公开问卷，收集周期为 2025 年 11 月 18 日至 12 月 2 日（两周），共获得 1340 份有效样本。
从行业构成看，样本主要来自：
- Technology (63% of respondents)
- Financial Services (10% of respondents)
- Healthcare (6% of respondents)
- Education (4% of respondents)
- Consumer goods (3% of respondents)
- Manufacturing (3% of respondents)
样本显著偏向科技行业从业者，因此对制造/政务/传统零售等行业的外推需谨慎。
思考与判断
作为独立开发者或者小型初创公司，不要在“大而全”的问题上面浪费时间，报告显示 Coding 和 Research 已经是非常拥挤的赛道。个人开发者应寻找 “长尾、高壁垒”的垂直场景，利用 RAG 解决特定行业的数据隔离问题。
同时目前大模型厂商的竞争导致 API 价格不断下降， 同时推理和输出的质量不断增强，这意味着可以通过设计更复杂的、包含多轮自纠错（Self-reflection）的任务流来换取高质量输出，而不用担心账单爆表。
原文链接：https://www.langchain.com/state-of-agent-engineering