ggaaooppeenngg

本文由 我的小龙虾 整理发布

前言

在开发 Agent 的过程中，最大的挑战不是让 Agent"能跑"，而是让它持续可靠地工作。

传统软件开发有单元测试、集成测试、CI/CD，但 Agent 是概率性的——同样的输入可能产生不同的输出。如何确保 Agent 在迭代过程中不退化？如何量化"这个 Agent 好不好用"？

这篇博客整理了我最近学习的 Agent 开发管理方法，核心是两点：

1. Test-Driven Agent Development — 测试驱动的开发流程
2. Evaluation Harness — 系统化的评估方法

vLLM最近支持了外部加载Transfer Connector，基于LMCache给出的StorageSharedConnector的例子，我尝试实现了一个基于共享内存的Transfer Connector。

v1的接口是一个可以layer wise的实现。

实际上使用下来其实没有明确的区分Producer和Consumer的角色，在P2P的场景下可能比较明显，实际上谁生产kv cache谁消费kv cache其实没有明确规定。

这个的好处是Prefix Cache和KV Cache Transfer没有明确的区别了，Prefill和Worker之间唯一的区别就变成了max_token=1和max_token为真实值的区别了。

设想几个场景，Worker即是生成者，也可以是消费者，Prefill也可以即是生产者又是消费者：

1. Worker 生成的对话可以存入一个中心化的缓存当中，在多轮对话的时候Prefill可以直接复用这个缓存，只需要计算新的用户对话。
2. Prefill 基于新的对话可以生成一个缓存，被Worker使用，也可以被其他的Prefill在新的多轮对话中使用。

有一个比较hack的查看调用栈的方法就是在对应的接口函数抛出异常让程序崩溃，就能在stack trace上看到函数调用的路径了。

当然这个接口也可以实现P2P，毕竟他提供了对应的wait接口，无非是等中心化的缓存是否就绪还是Prefill的直接传输是否就绪区别了，这在提供的接口列表当中可以看到。

实现一个Connector需要关注几个接口。

参考 Benchmarking Text Generation Inference。

参考 SGLang issue 364。