Cleric 是一款 AI 代理，旨在帮助工程团队调试生产问题，重点关注那些通常会消耗工程生产力的复杂且耗时的调查。
当警报触发时，Cleric 会利用现有的可观察性工具和基础设施自动开始调查。与人类工程师一样，Cleric 会同时检查多个系统——通过对生产系统的只读访问，检查数据库指标、网络流量、应用程序日志和系统资源。这种并行调查方法有助于快速识别复杂问题，例如微服务之间的级联故障。
Cleric 通过 Slack 与团队沟通，共享其发现并在需要时寻求指导。无需学习新工具——Cleric 可与现有的可观察性堆栈配合使用，如同人类工程师一样访问日志、指标和跟踪。
在 LangSmith 中同时进行生产问题调查
生产问题提供了独特的学习机会，这些机会无法在事后复制。与代码生成不同，生产环境是具有状态且动态的。一旦问题得到解决，确切的系统状态就会消失，学习它的机会也随之消失。
Cleric 团队需要同时测试不同的调查方法。例如，一种调查路径可能优先检查数据库连接池和查询模式，而另一种则首先关注网络流量和系统资源。这种设置会创建复杂的并发调查矩阵，因为 Cleric 会使用不同的调查策略检查多个系统。
这种方法带来了一个新的挑战。Cleric 团队如何监控和比较同时运行的不同调查方法的性能？他们如何确定哪种调查方法最适合不同类型的问题？
LangSmith 通过提供对这些并行调查和实验的清晰可见性，帮助解决了这个问题。有了 LangSmith，Cleric 系统现在可以
- 并排比较不同的调查策略
- 跨所有系统跟踪调查路径
- 汇总不同调查方法的性能指标
- 将用户反馈直接关联到特定的调查策略
- 直接比较处理同一事件的不同方法
LangSmith 的跟踪功能使 Cleric 团队能够分析数千个并发跟踪中的调查模式，衡量哪些方法始终能更快地解决问题。这种数据驱动的验证对于构建可靠的自治系统至关重要，因为仅依赖一次有效的方法不足以确保其通用性。
跟踪反馈和性能指标以泛化跨部署的见解
Cleric 在每个客户环境中持续从交互中学习。当工程团队对调查提供反馈时——无论是积极的还是消极的——这都为改进未来的调查创造了机会。虽然在单个团队或公司内部学习很有价值，但 Cleric 也认识到将其成功的调查策略推广到我们所有部署的潜力。
挑战在于确定哪些学习是特定于团队或公司的，哪些代表了可以帮助所有用户的更广泛的模式。例如，在一个环境中有效的解决方案可能依赖于不存在于其他地方的特定内部工具或流程。
在泛化任何学习之前，Cleric 会采取严格的隐私控制和数据匿名化措施。在分析或共享任何模式之前，会剥离所有特定于客户的详细信息、专有信息和识别数据。
Cleric 使用 LangSmith 来管理这个持续学习的过程
- 当 Cleric 完成调查后，工程师会通过他们与 Cleric 的正常互动（Slack、工单系统等）提供反馈。
- 此反馈通过 LangSmith 的反馈 API 捕获，并直接关联到调查跟踪。Cleric 存储调查的具体详细信息以及导致其解决的关键模式。
- 系统会分析这些模式，创建通用的记忆，剥离特定于环境的详细信息，同时保留核心的解决问题方法。
- 这些通用的记忆随后会在所有部署的新调查中选择性地提供。LangSmith 有助于跟踪这些记忆何时以及如何使用，以及它们是否能改善调查结果。
- 通过比较不同团队、公司和行业的性能指标，Cleric 可以确定每个学习的适用范围。某些记忆可能仅在一个特定团队内有用，而其他记忆则能在所有客户部署中提供价值。
LangSmith 的跟踪和指标功能使 Cleric 团队能够衡量这些共享学习的影响。系统可以在引入新记忆之前和之后，比较调查成功率、解决时间和其他关键指标。这种数据驱动的方法有助于验证哪些学习真正适用于不同环境，哪些应该仅限于特定客户。
该系统允许 Cleric 维护独立的知识空间——针对独特环境和程序的特定客户上下文，以及一个不断增长的、造福所有用户的通用问题解决模式库。
迈向自主、自愈系统
生产系统正变得越来越自主。工程的未来是构建产品，而不是操作它们。Cleric 解决的每一次事件都推动了这种转变，系统地将操作从人类工程师转移到 AI 系统，让团队专注于战略工作和产品开发。
Cleric 正在系统地构建这个未来，扩展自主能力，同时保持生产系统所需的安全性和控制力。每一次调查都有助于 Cleric 学习和改进，从而使其客户朝着真正自愈的基础设施迈进。要了解 Cleric 今天如何帮助您的团队，请 联系我们。