GenericAgent China-Stability Fork

[user141514]

A GenericAgent fork focused on stabilizing tool use, OpenAI-compatible provider support, and network/runtime reliability for China-accessible model endpoints.

[user141514]

现在glm也可以正常接入这个智能体了！

[user141514]

推荐使用国内网络，如果用的是国内的模型

[user141514]

GenericAgent China-Stability Fork

中文说明

这个分支的目标很直接：

让 GenericAgent 在中国可用模型接口、本地复杂网络环境、以及真实日常使用场景下，变得更稳定、更可用。

它不是对原项目的大改版，也不是推倒重来，而是一次非常务实的稳定性增强。

这个分支解决了什么

1. 工具调用更稳定

这个分支重点加固了 Agent 的工具调用链，减少模型出现以下问题的概率：

• code_run 空参数调用
• 把 temp/ 误认为当前项目根目录
• 上下文压缩后丢失关键工具规则
• 被 thinking 这类伪工具调用打断流程

实际效果就是：

• 少一些无效回合
• 少一些格式错误的工具调用
• “读文件 -> 分析 -> 继续执行” 这条链路更顺畅

2. 更适合 OpenAI 兼容接口

这个分支改进了 OpenAI 兼容请求路径，尤其适合中国可用的兼容端点。

包括：

• 正确支持非流式请求
• 更清晰的超时处理
• 区分 connect_timeout 和 read_timeout
• 在网络不稳定时表现更稳一些

这对使用替代 provider、国内可用接口、兼容 OpenAI 的模型服务尤其有帮助。

3. 运行时行为更安全

这个分支还加入了一些很实用的保护：

• 避免在常见请求路径中继承错误的系统代理行为
• 模型发出非法工具调用时，给出更明确的纠错提示
• 补充了工具约束和 provider 行为测试

目标很简单：

当问题发生时，系统应该更容易定位、更容易恢复，而不是随机卡死或莫名其妙地失败。

适合什么人

这个分支特别适合下面这类用户：

• 想用 GenericAgent 接中国可用模型接口的人
• 使用 OpenAI 兼容 API 的人
• 觉得上游项目“能跑，但不够稳”的人
• 更在意“日常能用”而不是“完全保持上游原貌”的人

一个很关键的现实结论

我们在实际排查里发现，最大的问题往往不是 key 本身，而是网络路径。

如果你使用：

• VPN
• Clash
• Mihomo
• TUN 模式
• fake-IP 模式
• 透明代理

那么即使 key 是对的，接口也可能表现得很不稳定。

常见症状包括：

• RemoteDisconnected('Remote end closed connection without response')
• SSLError
• ReadTimeout
• 同一句请求这次能过，下次又失败

这个分支下，更稳定的使用方式通常是：

• provider 请求不走 VPN，或者
• 给 provider 域名单独设 DIRECT

一句话总结就是：

key 有效并不代表一定稳定，网络链路同样关键。

这个分支不是什么

这个分支并不是：

• 重写原项目架构
• 替换原本 UI
• 把项目改造成完全不同的 Agent 框架

它仍然尽量贴近上游，只修补那些真正影响实际可用性的粗糙边缘。

你可以快速理解它的价值

• 更强的工具调用约束
• 工具执行后的续跑更稳定
• OpenAI 兼容后端支持更实用
• 超时处理更清晰
• 模型输出异常时更容易恢复
• 对中国网络环境更有针对性

谁应该试这个分支

如果你觉得上游项目“很有潜力，但总有点不稳”，这个分支就是为这种情况准备的。

如果你的感受是：

“模型本身没问题，但 Agent 框架这一层不够稳定”

那这个分支正好就是在补这个缺口。

推荐仓库简介

一个面向实际可用性的 GenericAgent 分支，重点增强工具稳定性、OpenAI 兼容接口支持，以及中国可用模型端点下的真实使用可靠性。

---

English Overview

This fork focuses on one thing: making GenericAgent noticeably more usable with China-accessible model endpoints and real-world local environments.

It is not a redesign of the project. It is a practical stability pass for people who want the original project to work more reliably in day-to-day use.

What This Fork Improves

1. More Reliable Tool Calling

This fork hardens the agent's tool-use loop so the model is less likely to:

• call code_run with empty arguments
• confuse the scratch temp/ directory with the project root
• lose key tool rules after context compression
• get derailed by pseudo-tool noise such as thinking

In practice, this means fewer wasted turns, fewer malformed tool calls, and a smoother "read file -> think -> continue" workflow.

2. Better OpenAI-Compatible Provider Support

This fork improves the OpenAI-compatible request path used by alternative providers and China-available endpoints.

Notable improvements include:

• proper non-stream request support
• better timeout handling
• clearer separation between connect_timeout and read_timeout
• more resilient provider-side request behavior in unstable network conditions

This is especially helpful when using non-default backends instead of the original Claude-native path.

3. Safer Runtime Behavior

This fork also includes practical defensive fixes:

• avoids inheriting broken system proxy behavior in common request paths
• improves recovery prompts when the model makes an invalid tool call
• adds tests for tool constraints and provider behavior

The goal is simple: when something goes wrong, the agent should fail more clearly and recover more often.

Best Use Case

This fork is best for users who:

• want to run GenericAgent with China-accessible model endpoints
• rely on OpenAI-compatible APIs
• need better stability than the unmodified upstream behavior
• care more about "usable in practice" than "pure upstream fidelity"

Important Network Note

The biggest real-world issue we found was not the API key itself, but the network path.

If you use VPN, Clash, Mihomo, TUN mode, fake-IP mode, or transparent proxy routing, some providers may become unstable even when the key is valid.

Typical symptoms:

• RemoteDisconnected('Remote end closed connection without response')
• SSLError
• ReadTimeout
• requests that succeed once and fail on the next turn

For this branch, the most stable setup is:

• no VPN for provider requests, or
• explicit DIRECT rules for the provider domain

In other words:

A valid key is not enough. A stable network path matters just as much.

What This Fork Is Not

This fork does not try to replace the original architecture, rewrite the UI, or turn the project into a completely different agent framework.

It stays close to upstream, while fixing the rough edges that matter most in actual usage.

Highlights At a Glance

• stronger tool-call constraints
• more reliable continuation after tool results
• improved OpenAI-compatible backend behavior
• clearer timeout handling
• better recovery from malformed model output
• practical guidance for China-network environments

Who Should Try This Fork

If upstream feels promising but flaky, this fork is for you.

If your experience has been "the model is good, but the agent is unstable," this fork is aimed exactly at that gap.

Suggested Short Description

A practical GenericAgent fork focused on tool stability, OpenAI-compatible provider support, and better real-world reliability for China-accessible endpoints.

[lsdefine]

Thanks a lot for the contribution — really appreciate the work here. The OpenAI non-stream support is a nice addition.

My main concern is that most of the prompt-related changes in this PR are still operating on the text-protocol tool-calling path. In practice, for weaker models, switching to the native tool interface tends to be a much more effective improvement than adding more prompt-level constraints.

So while some of these prompt-side adjustments may help in specific compatibility scenarios, I'm not sure they are the right long-term direction for the core branch. It may make sense to keep the non-stream/provider reliability parts, and be more conservative with the prompt/tool-protocol changes.

If possible, splitting those parts apart would also make review easier.

[user141514]

If possible, splitting those parts apart would also make review easier.

Thanks again for the thoughtful review — I think that’s a very reasonable concern.

I resolved the conflicts conservatively with that in mind:

• kept the non-stream / provider reliability parts
• trimmed back the more aggressive prompt-side / text-protocol changes
• tried to avoid pushing that direction further in the merged version

So the current result is meant to stay closer to the reliability-focused part of the PR, rather than treating prompt-level constraints as the main path forward.

I agree that separating those concerns would likely make the review much clearer. If you think that would be better, I’d be happy to split the remaining prompt/tool-protocol-oriented changes into a follow-up PR.