uni-agent 很慢，是什么回事

欢迎到专业群（ uni-agent技术交流群 ） 咨询，群中有相关专业的管理员和群友。

uni-agent 响应变慢通常不是单一原因造成的，而是上下文管理、模型选择和任务复杂度等因素叠加的结果。结合你的描述和历史对话，可以从以下几个方向排查和优化。

排查上下文窗口是否过载

当前会话如果已经进行了很多轮对话，或者之前让 uni-agent 读取了大量文件、日志，上下文窗口会变得非常臃肿。每次提问，模型都要重新“回顾”所有历史内容，这会导致响应显著变慢，同时消耗大量 token。

建议操作：

• 如果当前问题与之前的对话主题关联不大，直接新开会话。新功能、新模块、无关的 bug 修复，都应该用新会话处理，避免旧上下文拖慢速度。
• 如果已经在一个很长的会话里，但还想保留已有结论继续讨论，可以在输入框发送 /compact 命令。uni-agent 会压缩历史上下文，保留关键信息，大幅减少后续推理负担。
• 避免在聊天框直接粘贴大段代码或完整日志。让 uni-agent 自己通过文件路径或控制台去读取，这样它只会获取需要的内容，而不是把整个文件内容塞进上下文。

检查模型来源和档位选择

uni-agent 内置了模型切换策略，简单问答和复杂代码生成会分发给不同档位的模型。如果你当前的任务是跨文件重构、长上下文分析或复杂排错，而模型档位偏低，处理速度自然会慢。

建议操作：

• 确认 uni-agent 设置中的模型来源是“dcloud 订阅”还是“自定义 key”。默认推荐使用 dcloud 订阅模型，因为内置技能、知识库和调度策略主要围绕该来源优化。
• 如果是自定义 key 或中转站，网络链路更长，数据安全和稳定性也可能影响响应速度，复杂任务建议切回 dcloud 订阅模型。
• 检查当前订阅类型和资源包余额，确认是否因为额度问题导致服务降速。具体余额和套餐信息以 dcloud 开发者中心 展示为准。

让 uni-agent 自动化执行，减少人工等待

很多时候感觉“慢”，是因为你在等它完成一个本可以自动闭环的任务，而你没有充分利用它的自动化能力。

建议操作：

• 对编译错误，不要自己复制报错再贴给它。直接告诉它：“自己读 hbuilderx 控制台的编译日志，把所有编译错误修好，直到编译通过”。它会一轮轮自动读取日志、修改代码、再次编译，你只需要喝茶等待最终结果。
• 对运行时的 bug，告诉它：“自己在关键位置加 log，运行到 android 控制台，读取日志分析原因并修复”。让它自己完成“改代码 -> 运行 -> 读日志 -> 再改”的闭环。
• 对 ui 问题，提供期望效果图后，告诉它：“自己截图对比，分析哪里不对并修正”。它会自动运行页面、截图、对比、修改。

这种自动化工作流才能真正发挥 uni-agent 作为“数字员工”的价值，你的等待时间也会从“盯着屏幕干等”变成“去做别的事情，回来验收结果”。

检查网络和本地环境

如果以上都正常，但所有操作都明显卡顿，可能是网络或本地环境问题。

建议操作：

• 检查是否有代理、vpn、防火墙或安全软件拦截了 uni-agent 的 api 请求。尝试关闭代理后重试。
• 确认 hbuilderx 和 uni-agent 插件都是最新版本。旧版本可能存在性能缺陷或连接策略问题。
• 如果电脑配置较低，同时开启了多个 hbuilderx 窗体并行跑 uni-agent，也可能因资源竞争导致响应变慢，适当减少并行任务数。

如果问题持续存在

可以加入 uni-agent 技术交流群 反馈具体情况，提供你的 hbuilderx 版本、模型来源、任务类型和慢的具体表现，方便进一步定位。