LLMAgent应用研发在当下是一个非常热门的话题，目前一个典型的趋势是，各类垂类领域都在思考LLMAgent如何能够代替人力，为其业务场景赋能，一方面是常规提效，另一方面是深度挖掘CornerCase。恰巧笔者最近在做变更风险防控领域LLMAgent应用的技术调研，所以今天这篇博客，也简单分享一下调研来的一些思考。
主要分两个部分，第一部分是LLMAgent可以用在变更风险防控的什么环节，第二部分是系统化落地需要考虑做什么事情。
先说第一部分，背景上，对于变更风险防控，其理想的终态是实现变更过程的无人值守，如果是纯Agentic模式的话，数据层面是需要一个高实时性可用性的变更上下文数据总线，然后应用层面需要一个具备丰富专家经验的Agent，能够判断变更前需要搜集哪些上下文，变更中需要观测什么，给出什么结论，变更后需要怎么做风险总结。当然这个事情会比较理想化，开发一个这样的Agent还不如纯工程来的实惠，所以整套架构形态还是以工程化的方式驱动，部分环节通过Agent深度挖掘，这种形式比较合理。
然后是Agent可以在哪些场景用上。首先是变更上下文数据的搜集，Agent可以循环往复去做深度搜集，然后把数据投到上下文总线给后面的流程用到；其次是变更风险的深度分析和总结，这部分可以增强变更风险判断的可靠度，也能够帮助研发去缩短变更风险的响应时间；还有就是变更静态规则校验，也可以以Agent驱动的方式自主做检查并汇总风险。这些场景的如果通过纯工程实现，要么扩展成本比较大，要么确定性存疑，所以用Agent来落地会比较合适。
第二部分是怎么系统化落地这些功能，这里面需要考虑的除了技术实现本身之外，产品上也需要做一些必要的开放性，使得各专项Agent能够做灵活的扩展。举一些例子，对于静态规则校验，可以允许外部开发者面向特定的变更场景，通过Skill或Prompt+MCP的方式自定义校验规则；对于变更风险总结，可以允许外部开发者输入特定异常解读的知识，从而这些知识可以最终辅助到变更风险的判断当中，提升检测任务整体效果。所以，需要抽象一套面向内部的Agent资源基建，实现这些能力的支持。
当然，产品设计方面也需要考虑怎么在保障开放性的同时，能够兼顾实际应用的效果。如果人力成本比较充裕，可以像Datadog-Agents这样，为用户提供完整的AgentIDE，包含Workflow编排+大模型调用+各类ToolUse的能力。但如果主Agent是自己闭源，或者比较效果导向的话，一是对于用户交付的内容需要有审核机制（AI审/专家人审），二是适度开放，可以参考ServiceNow，只给Name/Description/Instructions这些类Skill的开放程度，而并非一套完整的AgentIDE形式。
总体来说，LLMAgent在变更风险防控，甚至扩展到任意垂类场景的应用，还是需要重点看相比纯工程实现，Agent能否带来增量结果，而并非为了技术而技术，研究了很多花里胡哨的Agent编排，但对实际应用效果没有一点提升。从现状来讲，笔者对于LLMAgent的大规模研发落地这件事情，还是保持一个谨慎的态度。在没有非常系统的Agent研发基建的情况下，研发LLMAgent的试错成本还是比较高的，所以找到具体的提升目标再下手比较合适。