我搭建的 agent 栈里,真正有价值的不是更好的检索,而是让一条客户变更自动触达正确的团队。
摘要
一位开发者介绍了如何构建连接六处客户数据源的 agent 栈,将记录映射到共享实体,并自动把变更路由给正确的团队。他认为实体解析和路由比单纯的检索创造更大价值。该系统在提出跨系统更新建议的同时,将权限控制和人工审批作为信任边界。
我连接了一家 B2B 公司存放客户上下文的六个来源:聊天、工单、wiki、CRM、邮箱和会议记录。第一版会检索全部六个来源并返回有依据的回答。这很有用,但它并没有消除真正的工作量。仍然需要有人注意到某张工单、某个 CRM 账户和某条会议记录指向的是同一个客户,判断哪个来源是最新状态,再把变更同步给需要的人。结果这更像是一个映射问题,而非检索问题。现在的中间层会将来源记录映射到共享实体上,同时保留来源、时间戳和引用的原文。当新的信号进入时,系统能判断它属于哪个客户、项目或决策,与当前状态比对,并只将变更路由给订阅该信息的团队。一次更新可以出现在客户变更雷达中,并生成对 CRM 或 wiki 的更新建议,无需人工在系统之间搬运信息。棘手的场景出奇地常见:公司更名;母公司与子公司共用联系人;人们把产品名当作客户名;CRM 显示活跃,而最新工单显示已阻塞;同一条决策以不同措辞出现在聊天和会议记录中。检索可以把这些全部返回,但它无法告诉你哪些信息属于同一实体,或者谁应该知情。权限仍然以提问者的身份运行,写入操作则作为建议提交给人工审批。我把这视为信任边界,而非核心价值。核心价值在于,一条决策不再被困在它所诞生的系统里。对于正在构建跨系统 agent 的人:当规模上来后,什么会先失败——实体匹配、判定当前真相,还是在路由变更时不把每个渠道都变成噪音?
相似文章
我的智能体架构:一个智能部分与一堆可靠部件
作者分享了构建AI智能体架构的经验,其中包含一个用于推理的智能AI组件和可靠的确定性工具以防止故障,强调了在日常任务中最小化模型自由裁量的价值。
我对多智能体系统最大的改进,是让智能体变得更不重要
一位实践者描述了如何重构一套生产级多智能体系统,使智能体变成可替换的执行者,嵌入在一套持久的架构之中——该架构以权威状态、任务契约、能力路由、独立验证和确定性检查为核心。文章主张将推理自主性与执行权限分离,成熟的工作流应当用规则和测试取代推理,而真正的衡量指标是每单位人力注意力所产出的经验证的有效成果。
@omarsar0: 我最近在做企业级智能体集成工作,很快就会发现局面会变得相当混乱。你很快就会发现,智能体的能力上限取决于它们在客户的 Salesforce 或 NetSuite 中能做什么……
这篇帖子讨论了企业级智能体(agentic)集成的问题,并介绍了 Ampersand(@WithAmpersand)——一种集成基础设施,让企业智能体能够通过单一的按客户配置(per-customer config)可靠地连接到 Salesforce、SAP、NetSuite 等客户的核心系统(system of record),由该配置统一处理认证、重试、数据回填和监控。
"在什么情况下添加另一个代理实际上会损害您的系统?问这个是因为我的6代理流水线比旧的2代理流水线更慢且更不可靠"
一位开发者分享了使用AI编排框架(LangGraph, CrewAI, AutoGen)的真实体验,指出了原型设计便捷性与生产可靠性之间的权衡,并向社区询问如何处理失败、人机协同和Token成本问题。
跨四个LLM层级的代理工作路由:编排器、顾问、深度推理、Premier
作者分享了一个实用的四层LLM路由栈,用于代理工作。其中,快速的编排器处理大部分请求,仅在需要深度推理时才会升级到昂贵的模型,显著降低了成本并提升了交互体验。