工程实践 Salesforce Engineering 2026/08/12
本文是 Salesforce Engineering Energizers 系列访谈，介绍 Trusted Services 团队如何基于 Agentforce 构建 Security Center，以加速安全调查与响应。团队将产品从单一对话界面扩展为有状态的调查平台，支持调查生命周期管理、修复跟踪、审计和可视化。面对 LLM 非确定性，他们构建了 AI 驱动的评估流水线，用 LLM 评估器判断响应是否满足调查目标而非逐字匹配，使测试吞吐量提升 10–20 倍。在推理深度与上下文窗口限制之间，团队通过提示工程、结构化动作路由、数据源控制和自动评估来缓解幻觉，并通过可扩展数据模型与 AI 摘要压缩异构遥测数据。文章还指出 Salesforce 特定安全知识 grounding 仍是持续挑战，整体提供了企业级 AI 安全工作流的工程案例，但部分内容带有产品宣传色彩。
推荐收录，因为它详细展示了将 LLM 智能体从对话界面升级为有状态安全调查平台的过程，包含非确定性评估、上下文窗口管理、幻觉缓解和异构遥测聚合等真实工程约束。适合从事 AI 安全、智能体工程或事件响应自动化的工程师借鉴，其 AI 驱动评估与数据分区/摘要策略可迁移到其他高可靠性场景。主要风险是内容带有产品推广性质，缺少量化指标和失败案例，但工程方法仍有参考价值。
工程实践 Salesforce Engineering 2026/08/11
文章介绍了Salesforce如何通过构建标准化的产品遥测平台（PDP）解决各产品团队各自定制遥测导致的数据孤岛、重复劳动和无法规模化的问题。PDP采用统一的遥测架构和自动化指标生成管道，要求团队遵循标准化的埋点规范，从而自动产出可信的产品采纳指标。技术上，它基于监控云基础设施构建了自定义模式，并处理每天450亿行事件数据，覆盖19000个事件和2000多个产品特性。实施后，洞察获取时间从约1个月缩短至每日刷新（降低97%），开发者埋点工作从数周减少到数小时，CSAT达9/10。标准化的数据基础也为AI分析工具和MCP集成提供了可信支撑。该工程案例适用于大规模多产品环境下集中式数据平台的建设与推广，但需注意组织推动和标准治理的复杂度。
本文是典型的工程实践复盘，提供了从问题识别、架构设计到规模化推广和量化的完整过程，尤其在统一数据标准、提升数据质量和自动化的权衡方面具有可迁移价值。适合负责数据平台、指标体系建设或开发者效率的工程师参考。量化结果（97%时间缩减）和推动团队采用的方法论具有说服力，有助于读者借鉴其建设可信数据基础、赋能AI工具的思路。
工程实践 Salesforce Engineering 2026/08/05
Salesforce内部可观测平台Argus需处理每分钟40亿指标，原单区域架构导致全局可用性风险及高昂的数据传输成本。团队采用地理本地化策略，将指标就近处理和存储，避免全量复制，并通过联盟查询层与Elasticsearch元数据映射实现智能路由，仅查询数据所在区域，减少跨区域开销。同时引入HTTP 206部分响应和UI提示来处理部分地域不可用，保障用户体验。文章还介绍了通配符查询的元数据缓存优化，以及持续容量规划和架构审查来维持隔离边界。该方案已在五个生产区域中的四个上线，显著降低爆炸半径，但跨区域延迟和流量成本仍为后续关注点。
这篇工程案例详实记录了如何将单区域可观测平台迁移到多地理架构，解决全局不可用风险并控制成本，包含查询联邦、部分失败处理和元数据缓存等关键设计，为构建高可靠、大规模可观测系统的团队提供了可复用的架构思路和实践参考。
职业经验 Salesforce Engineering 2026/07/30
文章分享了Salesforce为数千名软件工程师构建代理工程赋能策略的实践经验。作者指出企业级代理工程的核心瓶颈并非模型能力，而是组织学习能力：工程师自然会产生不同工作模式，但缺乏共享语言会导致实践碎片化。为此，他们设计了一个四阶段熟练度框架（AI辅助、验证、编排、原生），以行为变化而非工具熟练度衡量进展，并通过AI训练营、周会、教练指南等项目帮助工程师实践跨越。文章最后提出四条可迁移原则：规模化共享期望、学习旅程优于评估框架、行为变化是关键指标、学习文化重于任何框架。文章侧重组织赋能和文化建设，但未提供具体量化效果数据。
推荐收录。该文从工程组织赋能的角度提供了真实、系统的转型经验，提炼出的熟练度框架和原则可直接迁移到其他大型工程团队，尤其适合技术领导者和团队管理者参考。它避免了纯工具推广，强调了行为改变和共享语言的重要性，具有长期参考价值。
工程实践 Salesforce Engineering 2026/07/27
文章以 Salesforce Agentforce Grid 为案例，深入剖析从 AI 原型转向生产系统时面临的分布式执行挑战。作者指出，生产 AI 的核心问题不是模型行为，而是如何让智能在长时运行、部分失败、部署重启、重试和输入变化中保持可靠。文章提出通过持久工作流将执行状态与工作线程生命周期解耦，并围绕可恢复的工作单元划分、执行状态持久化、重试边界对齐恢复边界、分层进度可见性等设计决策展开讨论。内部测试显示，迁移到 Temporal 后，高负载下失败率从约 90% 降至 0%，P95 完成时间缩短约 60%，验证了该架构的有效性。文章适用于涉及大规模批量推理、多步 Agent 或工具调用的 AI 工程场景，但数据来自内部环境，外部应用需独立验证。
推荐收录，因为文章基于真实生产系统，完整呈现了从问题识别到架构演进的工程决策过程，提供了可迁移的工作单元划分、状态持久化与重试设计原则。适合从事 AI 工程化、大规模分布式推理和可靠工作流编排的工程师与架构师阅读，能直接帮助读者在类似系统中避免“重跑全部任务”的陷阱，提升整体可靠性。
工程实践 Salesforce Engineering 2026/07/23
本文是Salesforce工程团队关于用LLM重建本地化管道的实践总结。面对产品量激增35%而预算与发布时间窗口固定的矛盾，团队从尝试单一LLM提示翻译失败中认识到，企业本地化不仅要翻译文本，还需处理客户自定义对象、多产品术语和34种语言的语法与品牌规则。最终的方案是构建一个AI编排管道，将提示工程与上下文工程结合，为每个翻译任务注入产品、品牌、语法等结构化上下文，并通过多阶段AI编辑与验证（最多85个专门提示阶段）来保证质量。该管道将本地化成本降低50-90%，大幅加速交付，同时建立了可持续的工程基础。文章还讨论了未来面对的模型演化与发布工程挑战。
文章完整展示了一个将AI深度集成到遗留企业系统的工程案例，从问题分析、架构设计、验证策略到反馈循环，提供了可迁移的上下文工程与多阶段验证模式。对于负责国际化、AI工程化或大型系统现代化的工程师和架构师，其思路与权衡具有直接参考价值。需要注意的是，方案高度依赖高质量的结构化上下文资产，且需应对基础模型持续演进带来的维护挑战。
工程实践 Salesforce Engineering 2026/07/21
本文详细记录了Salesforce内部AI系统BugWiser的构建过程，旨在将客户缺陷分类和根因分析从超过300人天的手动流程缩短至一周以内。团队面临的核心挑战不是单纯应用AI，而是将多年工程判断编码为一套可信的自动化分类框架。解决方案融合了自定义机器学习模型（用于确定性分类、置信度评分与可解释性）和大语言模型（用于综合上下文和生成摘要），并设计了基于置信度的自动接受与人工反馈闭环，使约90%的预测无需修改。文章还探讨了模型选择、训练、部署及工程文化转变的具体权衡，强调‘信任设计’是该系统的支柱。其边界在于依赖Salesforce内部历史缺陷数据，并需要持续的工程师反馈来保持模型与专家认知对齐。
本文是一个高质量的工程案例，展示了在大型组织内如何通过AI工程化手段解决真实的质量与效率问题。它对面临类似‘专家依赖型’人工流程的团队具有直接参考价值，尤其在如何组合专用模型与通用LLM、如何通过置信度与反馈循环构建工程师信任、以及如何衡量生产力提升等方面提供了可迁移的设计模式。适合负责工程效能、质量保障或AI系统落地的工程师和管理者阅读。
工程实践 Salesforce Engineering 2026/07/17
本文来自 Salesforce 工程团队的实践复盘，介绍如何围绕一个技能生成器构建自动化反馈闭环，逐步形成自改进的 AI 系统。核心方法包括三层评估框架：触发准确性测试、结构确定性验证以及基于 LLM 的语义评判，用于量化生成器质量；同时设计了一套每周自动运行的信号挖掘与改进流水线，从多人 PR 评论中提取高频模式，通过频率×严重性优先级进行有限修改，再由评估门控确保不退化。文章展示了系统在六次循环后自然收敛至稳态，并在约定变更时自动重启修正的现象，最后总结了该架构的适用前提：需要足够的审查信号量、结构化可验证的输出格式，以及一定的审查文化。全文提供了可迁移的评估与反馈模式，但也指出核心工件仍依赖人工最终确认，适用于有类似 AI 生成器与代码审查流程的工程团队。
本文不是空泛的方法论宣讲，而是基于真实工程场景的深度实践记录。它完整呈现了从发现重复审查痛点、设计多维度评估、实现自动化反馈到系统收敛与重启的全过程，并清晰框定了架构的适用边界与前提条件。对于工程团队在构建 AI 辅助工具、自动化流水线或希望将审核经验持续沉淀进系统时，文中的三层评估框架、带阻尼的反馈循环和收敛机制具有直接的可迁移性。
工程实践 Salesforce Engineering 2026/07/16
本文介绍了如何利用Claude Code在30分钟内构建一个衍生的AI知识库，通过将团队散乱的设计文档、Slack讨论等原始资料交由代理生成干净、互链的概念笔记和人员笔记，形成既可供人类浏览又可供AI代理快速检索的结构化Markdown集合。文章详细说明了文件夹结构、两条自定义技能‘/ingest-doc’和‘/refine’的设置与使用，并通过实例演示了从摄入文档、推导笔记到迭代精炼的完整流程。最后讨论了成本控制、可信任边界和随时可重建的灵活性，并指出该模式已在作者团队持续运行超过6个月，适用于代码仓库、客户记录等多种知识密集型场景。
推荐收录。文章提供了真实团队长期使用AI代理构建和维护知识库的工程案例，步骤清晰、可直接复现，且揭示了推导、精炼等核心设计原则，可迁移到任何需要管理技术文档或组织知识的场景，对AI工程实践者和团队负责人有较高参考价值。
工程实践 Salesforce Engineering 2026/07/09
本文以Informatica Copilot为例，介绍如何通过自然语言生成数据集成管道，将开发时间从数天缩短到数分钟。文章回顾了从微调模型转向OpenAI的架构决策、应对模型快速演进的测试策略，以及通过提示工程、上下文增强和验证层提升准确性的方法。客户已生成约10,000条管道，表达式自动生成采纳率约60%，表明AI辅助显著提升效率。核心结论是生成式AI的准确性更依赖上下文与防范机制而非模型规模，并提出未来将支持代码优先和代理式工作流。案例局限于数据集成领域，但工程思路具有可迁移性。
推荐收录，因为文章提供了从模型迁移、非确定性系统测试到提示调优与验证的完整工程案例，并附有客户采纳数据作为证据。适合正在构建AI特性尤其是LLM集成的工程师阅读，可借鉴其迭代适应基础模型、通过验证层保障准确性的实践。主要迁移价值在于揭示了提升AI系统精度不依赖更大模型，而在于上下文设计与保护机制。
工程实践 Salesforce Engineering 2026/07/06
文章围绕 Salesforce 在 Agentforce 中构建企业 AI Agent 的实践，提出“guided determinism”作为核心架构：用确定性的编排层约束 LLM 的概率性输出，让代理在身份验证、退款授权、升级路由等高风险流程中保持可审计、可恢复和可验证。作者用退款代理误把“very valid and very verified email”当作证据的例子说明，单靠 prompt engineering 无法提供企业所需的规则保证，因此需要把工作流建模为 Agent Graph，由节点、边、硬校验门和运行时状态共同控制执行路径。文中进一步说明用专门子代理拆分路由、验证、冲突消解和事务处理，并在路由环节采用 8B 到 32B 的小型微调模型以降低延迟和成本。最后，文章强调通过合成测试、LLM 评审、深度 trace 和行为指标持续验证运行时可靠性。其边界在于这套方法主要适用于有明确流程与高可靠要求的企业任务，对开放式创意对话并不追求完全确定性。
文中给出了从提示词到运行时编排的完整架构迁移证据，包括 Agent Graph、子代理拆分、小模型路由和可观测性体系，属于可复用的企业 AI 工程经验。适合做 AI 平台、工作流自动化和高风险交易代理设计的参考，但需注意其结论带有明显产品实现视角。
工程实践 Salesforce Engineering 2026/07/01
文章介绍 Salesforce Mobile CI/CD 团队如何把八年积累的移动构建排障经验，抽象成名为 Analyze Build Tools 的 AI 排查系统。该系统不再只展示仪表盘，而是像资深支持工程师一样基于假设主动收集证据，联动 Managed Pipelines、Splunk、历史构建和内部指标，判断失败更可能来自应用代码、平台基础设施还是 Apple/Google 外部变更。它通过 /mp-investigate-build 等能力，让开发者直接询问“为什么失败”，减少人工拼接日志和跨系统检索的成本。作者给出明确成效：事故解决时间约缩短 60%，构建失败分析工作量下降 75%，使 8 人团队能够支撑 60+ 仓库和更多移动工程师。文章也指出当前系统仍以事后排障为主，下一步是做异常检测与主动告警，但告警噪声控制将决定其可用性。
推荐收录，因为文章给出了从“看仪表盘”到“像支持工程师一样做假设并取证”的具体工程方法，并用 60% 与 75% 两组结果证明了其价值。适合做移动 CI/CD、AI 辅助运维和开发者效率系统的参考，尤其对共享平台如何规模化支持多仓库、多团队场景具有可迁移意义。
工程实践 Salesforce Engineering 2026/06/29
文章介绍 Salesforce 为 Agentforce 构建的 Unified Planner：一个统一的 AI 执行与推理运行时，用来同时支撑语音、文本、聊天以及 MuleSoft 等场景。作者解释了旧体系中 Agent Graph 与 Voice Planner 各自演进导致的能力割裂、重复实现和运维不一致，并通过将平台级职责与客户业务流程解耦来完成统一。性能上，团队把原先串行的提示注入检测、检索、校验、上下文收集等步骤改为可并行执行，并允许多工具调用并发，从而把部分响应延迟从约 20 秒降到 2.3 秒。文章还讨论了模型选择、迁移生产代理的安全验证、特性分阶段放量，以及面向视频等未来多模态交互时在表示、推理和扩展性上的新挑战。整体更偏真实平台重构与 AI 运行时设计经验，适合关注低延迟 AI 系统、统一架构和生产迁移的读者。
收录理由明确：文中给出了统一运行时、并行化执行和生产迁移验证的具体做法，并量化说明了延迟从 20 秒降到 2.3 秒。适合做 AI 平台、Agent 运行时和多模态系统设计的参考，尤其对需要在低延迟、可扩展与一致性之间做取舍的工程团队有直接迁移价值。
工程实践 Salesforce Engineering 2026/06/23
这篇文章复盘了 Salesforce Agentforce 在 34 种正式支持语言和数十种 Beta 语言下，如何防止大模型在多步骤代理工作流中发生“语言漂移”。核心做法不是依赖 LLM 自行决定输出语言，而是在推理开始前通过低延迟语言检测建立可共享的 Localization Context，并让规划、检索、动作执行和响应生成都遵循同一语言契约。文章还讨论了分布式组件在并行执行、语言切换、回退策略不一致等场景下的失效模式，以及未来在评估、文化适配和中繁/简体等细粒度语言差异上的挑战。
推荐收录，因为它展示了大规模多语言 AI 系统里一个非常典型且可迁移的问题：如何把概率模型放进需要确定性约束的分布式工作流中。文章给出了明确的架构选择、延迟数据和失效边界，对做 AI 工程、代理系统或国际化产品的团队都有参考价值。