在那篇《LLM as Co-integrator：重塑团队间交互，持续改进信息对齐》里，我们说道，为了更好的利用 AIGC 提升效能，我们的第二个阶段应该是：让 LLM 做一些协同工作，诸如于：构建多场景知识问答，降低知识检索成本、设计团队 API，打造智能助理。

于是，我们着手构建了 CoUnit，以探索 LLM 作为团队接口人，凑近团队间协同。我们参考了 Bleep 语义搜索引擎的设计，使用了 Rust、Sentence Transformer、Onnx 构建了本地化、离线的、低成本的向量化与语义搜索能力，GitHub：https://github.com/unit-mesh/co-unit 。

Why CoUnit？

在过去的几个月里，有大量的企业、团队在构建自己的智能客服、问答 AI 等等。回到软件开发来说，我们或许也需要一个类似的问答 AI，至少它会比 FAQ 更快、它会更加的友好。但是，如何让这样的 AI 问答应用更有价值呢？

一、从团队拓扑思考价值

我们应该思考：

• 哪些角色花费了大量的时间在集成的工作？
• 哪些知识（文档、API）是可以部分被查看的？
• 哪些团队包含了大量的组织所需要的知识？

再回到先前我们对于 AI4SDCL（AI 应用于软件开发领域）的探索，对于有大量集成工作的团队，只有构建 LLM as Integrator 的能力，才能帮助这个团队释放生产力。于是，结合团队拓扑的思想，我们会发现赋能型团队与平台团队是最需要这一类的工具。

赋能团队：由特定技术领域（如 DevOps、持续交付、自动化测试等）或者产品领域的专家组成，赋能给产品导向团队，提供工具、实践、框架、技术栈等方面的建议和支持。如『技术咨询团队』便是其中的一类，在国内有华为的软件教练，腾讯的敏捷教练等。

平台团队：向产品导向团队交付能高度自治的工作模式。他们向开发团队提供自服务的 API、工具、知识、服务和支持，典型的是各类的基础设施平台，如基础设施代码化的云原生相关的技术平台。

围绕于这两种类型的团队，构建跨团队的知识问答 AI 能更好辅助这些团队。

二、看不见的 Team API

在现实的软件开发中，我们一直要面临团队间的依赖关系问题。除了文档、wiki 等，还有上线日程安排和优先级问题，他们都会在一定程度上减缓交付流程。特别是，为了解决团队间的依赖问题，开发人员需要约定拉通会议的时间，也会拉慢团队的交付节奏。除此，我们还可以尽可能清晰地提供信息和团队的访问方式，以最大程度地减轻其他人的认知负担。

为此，在《团队拓扑》一书中，便提倡构建 Team API 来解决上述的问题，即提供文档、wiki、以及非敏感的代码，以及路线图、沟通偏好等等。而这些东西正好非常适合结合 LLM 来解决，即通过 LLM 来分析其他团队的需求，并根据知识库、开放 API 等信息来回答用户。

顺带一提，不同的团队可能更喜欢以不同的时间尺度（诸如两周一迭代、什么时候发布上线等等）工作，而这些则可以考虑在下一个 AI4SDLC 阶段来解决。

CoUnit 是什么？

简单来说：

CoUnit，一个基于 LLM 的虚拟团队接口人（Team API），通过向量化文档、知识库、SDK和 API 等，结合 LLM 智能化团队间对接与协作。

由于 HuggingFace 使用 Rust 语言构建了一系列的 AI 基础设施，加上开源的 Bleep 代码搜索引擎使用的是 Rust 语言，所以我们也使用 Rust 构建了一个本地语义化的代码搜索服务 —— 借助 Sentence Transformers 在本地进行向量化和搜索，无需联网。

基于 CoUnit，你可以进行：

• 语义化的代码搜索
• 语义化的 OpenAPI 搜索
• 语义化的 Http API 搜索
• 语义化的文档搜索
• ……

当然了，未来还可以加入更多的类型。从技术难度来说，这些并不是主要问题，实现功能一点也不难。难点是，如何提升搜索的精准度？，诸如于：如何结合好中文、领域专有名词进行搜索？

CoUnit 是如何工作的？

在使用 CoUnit 之前，我们需要准备好一系列的原数据，诸如于代码 API 等等。于是，我们在 CoUnit 实现了一个 ArchGuard 的服务端 API，它可以直接接受由 ArchGuard 上传的数据，并存储到向量数据库中。随后，我们就可以在 CoUnit 客户端使用，诸如于 AutoDev。

考虑到代码相关的一系列元素结构化数据，如文档、架构、API 定义等等，所以我们并不需要使用 OpenAI 来进行向量化，采用 Sentence Transformers 就可以实现语义文本相似性、语义搜索等功能。

CoUnit 工作过程示例

使用的交互过程如下：

1. 通过 API 向 CoUnit 提交用户的任务，诸如于：商户申请单(merchant order)查询。
2. API 将会返回对应的 prompt，由调用方调用对应的 LLM 生成分析结果。
3. 如下是其中的一个分析结果示例：

{
    "domain": "merchant",
    "query": "merchant: query merchant order",
    "natureLangQuery": "商户申请单查询",
    "hypotheticalDocument": "GET /api/merchant/order/query?order_id=(order_id)"
}

1. 根据上述的分析结果，分别调用 CoUnit 的分析引擎，即：英语语言查询、原生自然语言、假设性文档查询三种结果
2. 由应用分析决定接下来的操作。

小结

对于 LLM 协作跨平台协作来说，CoUnit 更多的是提供一种新的可能性，如果你也有兴趣，欢迎来加入我们：https://github.com/unit-mesh/co-unit 。