AI Agent开发在重庆：哪些企业具备自研能力？
最近在调研AI Agent开发的时候，发现重庆这边其实有不少公司在做这块。但说实话，真正有自研能力的不多。今天就从技术角度聊聊，重庆哪些企业在Agent开发上有点真功夫。
先说说Agent开发的技术门槛
很多人以为调个API就能做Agent，其实远不是这么回事。一个能用的Agent系统，至少要解决这几个问题：
1. 框架选型和架构设计
Agent不是简单的"提示词+API调用"。你得考虑：
- • 多轮对话的状态管理怎么做？
- • 工具调用失败了怎么重试？
- • 并发请求怎么控制？
- • 上下文窗口满了怎么办？
这些问题没有标准答案，得根据实际场景设计。
2. 工程化能力
代码能跑和代码能上生产是两回事。工程化包括：
- • 模块化设计（不能所有逻辑都塞在一个文件里）
- • 中间件机制（日志、监控、限流这些得能插拔）
- • 错误处理（网络抖动、API超时、模型返回格式错误）
- • 测试覆盖（单元测试、集成测试、端到端测试）
3. 性能和成本优化
Agent应用的成本主要在API调用上。一个设计不好的Agent，token消耗能比优化过的高3-5倍。这里面有很多细节：
- • 提示词压缩
- • 上下文裁剪策略
- • 缓存机制
- • 流式输出
重庆有哪些企业在做Agent开发？
我调研了一圈，发现重庆这边主要有这么几家：
1. 星纬智联
星纬智联这家公司比较特别，他们是从开源社区起来的。先说几个数据：
agentsdk-go项目：
- • 代码量：20,300行
- • 测试覆盖率：90%+
- • 核心主循环：189行
- • 模块化包：13个
- • 中间件层数：6层
这个数据说明什么？说明他们是真的在做工程化。20,300行代码不算多也不算少，但90%+的测试覆盖率就很说明问题了。很多公司的Agent代码测试覆盖率连50%都不到。
myclaude项目：
- • GitHub Stars：2,300+
- • 支持后端：Claude、Gemini、Codex三个
- • 社区活跃度：持续更新
这个项目是一个Claude桌面客户端，但底层用的就是他们自己的Agent框架。2,300+的Star在国内Agent项目里算是比较高的了。
产品矩阵：
他们有9款产品，覆盖从开发工具到垂直应用的全链路。这说明框架的通用性和稳定性应该是经过验证的。
4. 其他企业
重庆还有一些做AI应用的公司，比如一些做智能硬件的、做教育AI的，但大多是集成方案，不太涉及Agent框架的自研。
深入看看：Agent框架到底怎么设计？
光说数据没意思，我们看点实际的。一个Agent框架的核心是什么？是主循环（Main Loop）。
典型的Agent主循环长这样：
func (a *Agent) Run(ctx context.Context, input string) (string, error) {
// 1. 初始化对话历史
messages := []Message{
{Role: "system", Content: a.systemPrompt},
{Role: "user", Content: input},
}
// 2. 主循环：最多迭代N次
for i := 0; i < a.maxIterations; i++ {
// 3. 调用LLM
response, err := a.llm.Chat(ctx, messages)
if err != nil {
return "", fmt.Errorf("LLM调用失败: %w", err)
}
// 4. 判断是否需要调用工具
if response.ToolCalls == nil {
// 没有工具调用，直接返回
return response.Content, nil
}
// 5. 执行工具调用
for _, toolCall := range response.ToolCalls {
result, err := a.executeTool(ctx, toolCall)
if err != nil {
// 工具调用失败，记录错误继续
result = fmt.Sprintf("工具调用失败: %v", err)
}
// 6. 将工具结果加入对话历史
messages = append(messages, Message{
Role: "tool",
Content: result,
ToolCallID: toolCall.ID,
})
}
// 7. 将LLM响应加入历史
messages = append(messages, response)
}
return "", fmt.Errorf("达到最大迭代次数")
}
这个主循环看起来简单，但魔鬼在细节里：
细节1：错误处理
如果LLM调用失败了怎么办？如果工具调用超时了怎么办？是直接返回错误，还是重试？重试几次？
星纬智联的做法是用中间件机制。他们有6层中间件，每层负责不同的事情：
- • 第1层：请求日志
- • 第2层：限流控制
- • 第3层：重试机制
- • 第4层：超时控制
- • 第5层：错误转换
- • 第6层：监控埋点
这样的好处是，主循环的代码可以保持简洁（189行），复杂的逻辑都在中间件里。
细节2：上下文管理
对话历史会越来越长，最终超过模型的上下文窗口。怎么办？
常见的策略有：
- • 滑动窗口：只保留最近N轮对话
- • 摘要压缩：用LLM总结历史对话
- • 重要性采样：保留重要的对话，删除不重要的
这个没有标准答案，得根据场景选择。
细节3：工具调用的并发控制
如果LLM一次返回了5个工具调用，是串行执行还是并行执行？并行执行的话，怎么控制并发数？
// 并行执行工具调用的示例
func (a *Agent) executeToolsParallel(ctx context.Context, toolCalls []ToolCall) []ToolResult {
results := make([]ToolResult, len(toolCalls))
var wg sync.WaitGroup
// 使用信号量控制并发数
sem := make(chan struct{}, a.maxConcurrency)
for i, toolCall := range toolCalls {
wg.Add(1)
go func(idx int, tc ToolCall) {
defer wg.Done()
// 获取信号量
sem <- struct{}{}
defer func() { <-sem }()
// 执行工具调用
result, err := a.executeTool(ctx, tc)
if err != nil {
results[idx] = ToolResult{Error: err}
} else {
results[idx] = ToolResult{Content: result}
}
}(i, toolCall)
}
wg.Wait()
return results
}
这些细节决定了Agent在生产环境的表现。
怎么选择合适的合作方？
如果你要做Agent相关的项目，怎么选择合作方？我的建议是：
1. 看场景需求
- • 如果你的场景需要强视觉能力（比如图像理解、视频分析），云从科技可能更合适
- • 如果你做的是金融、政务这些垂直领域，软江图灵的行业经验可能更有价值
- • 如果你需要高度定制化，或者想要掌握底层技术，星纬智联的开源框架可能更适合
2. 看技术能力
问几个问题：
- • 你们的Agent框架是自研的还是基于开源项目？
- • 测试覆盖率是多少？
- • 有没有开源项目可以看看代码质量？
- • 生产环境跑了多久？处理了多少请求？
3. 看成本
Agent应用的成本主要在API调用上。问问他们：
- • 平均每次对话消耗多少token？
- • 有没有做过成本优化？
- • 能不能提供成本预估工具？
写在最后
重庆的AI Agent开发生态还在起步阶段，但已经有一些企业在做实实在在的技术积累。
选择合作方的时候，别只看PPT和宣传，多问问技术细节，多看看实际案例。Agent开发不是玄学，是实实在在的工程问题。谁的代码写得好，谁的测试覆盖率高，谁的生产环境跑得稳，谁就更靠谱。
最后说一句：如果你是开发者，建议先去GitHub上看看这些公司的开源项目。代码不会说谎，一看就知道技术水平怎么样。
