Reorx’s Forge 头像

消息来源频道

Reorx’s Forge

@reorx_share

频道3,130 位成员公开可见0 人在线

A chronicle of my journey in forging my ideas into writings and products. Archive: https://app.shokichan.com/c/tg/reorx_share

成员规模3,130 位成员
在线情况0 人在线
消息总数6,041 条消息
浏览量总数784,746 次浏览

在这个频道里搜索消息……

t.me/reorx_share

记一次开源软件的「买椟还珠」
Arch 是一个 LLM API 网关,它基于 Envoy 开发,且开发者也来自 Envoy 贡献者,所以作为一个网关软件的品质是有保障的。
https://github.com/katanemo/archgw
Arch 的基础功能是支持配置多个 LLM provider,用户只需指定 provider 名称,即可通过统一的 endpoint 访问对应模型。从架构上看,Arch 应该具备兼容不同 API 标准(如 OpenAI、Claude、Gemini)的能力,但目前只实现了 OpenAI 的接口,且缺乏统一抽象和互通转换功能。
Arch 比较亮眼的一个特性是 Prompt Guard。开发团队专门训练了一个名为 Arch-Guard 的分类器模型,用于对用户的 prompt 进行过滤与分析,以保护下游 LLM 免受 prompt injection 等攻击。这一功能有效地将开发者从提示词安全防护这类必要却繁琐的工作中解放出来,颇具实用价值。
Arch 另一个值得关注的功能是 Prompt Target。它允许开发者在配置中声明工具,使网关本身具备调用工具的能力。比如可以定义一个获取货币列表的工具和一个汇率转换工具,接入任意 LLM 后就能回答用户的汇率查询请求,哪怕该 LLM 原生并不支持函数调用。
类似 Arch-Guard,Arch 还训练了另一个模型 Arch-Function,用于识别是否需要调用工具,并在调用后将结果融入提示词再发送给 LLM。尽管这个设计思路巧妙,但也存在一些问题:开发者无法干预工具调用的识别过程、无法引入用户确认机制、也无法通过代码灵活地定义工具逻辑。在我的使用场景中,更倾向于将 agent 的实现逻辑保留在应用层,让整个流程清晰可控。网关应专注于 routing、rate limiting、security、transformation、observability 等职责,而不是替代应用做 agent 决策。不过,对希望快速搭建原型的开发者来说,Arch 的这种设计仍不失为一种省力的选择。
总体而言,Arch 作为一款 LLM 网关,当前的核心能力仍不够完善,尤其在 LLM 支持和传统网关功能上尚有欠缺。Prompt Target 虽然看起来强大,但实际使用中因缺乏可控性而不太适合复杂的 agent 应用。然而,它自主研发的 Arch-Guard 和 Arch-Function 两个模型却展现出不小的潜力,未来或许可以作为通用的安全模块或工具调度中间层使用,这也促使我决定进一步深入研究。
回过头来看,Arch 最吸引人的,并不是它作为网关本身的功能,而是它所附带的两个模型——Arch-Guard 和 Arch-Function。如果说 Arch 是椟,那这些模型或许才是更值得珍视的“珠”。这让我意识到,开源项目中的附加组件,有时反倒蕴含着更大的价值 。