Github Copilot Agent模式使用经验分享

Github Copilot Agent模式使用经验分享

本文总结了如何使用 GitHub Copilot Agent 模式,并分享实际操作经验。

前置设置

  1. 使用 VSCode Insider;
  2. 安装 GitHub Copilot(预览版)插件;
  3. 选择 Claude 3.7 Sonnet(预览版)模型,该模型在代码编写方面表现出色,同时其它模型在速度、多模态(如图像识别)及推理能力上具备优势;
  4. 工作模式选择 Agent。

操作步骤

  1. 打开 “Copilot Edits” 选项卡;
  2. 添加附件,如 “Codebase”、“Get Errors”、“Terminal Last Commands” 等;
  3. 添加 “Working Set” 文件,默认包含当前打开的文件,也可手动选择其他文件(如 “Open Editors”);
  4. 添加 “Instructions”,输入需要 Copilot Agent 特别注意的提示词;
  5. 点击 “Send” 按钮,开始对话,观察 Agent 的表现。

其它说明

  • VSCode 通过语言插件提供的 lint 功能可以产生 Error 或 Warning 提示,Agent 能自动根据这些提示修正代码。
  • 随着对话的深入,Agent 生成的代码修改可能会偏离预期。建议每次会话都聚焦一个明确的主题,避免对话过长;达到短期目标后结束当前会话,再启动新任务。
  • “Working Set” 下的 “Add Files” 提供 “Related Files” 选项,可推荐相关文件。
  • 注意控制单个代码文件的行数,以免 token 消耗过快。
  • 建议先生成基础代码,再编写测试用例,便于 Agent 根据测试结果调试和自我校验。
  • 为限制修改范围,可在 settings.json 中添加如下配置,只修改指定目录下的文件, 仅供参考:
"github.copilot.chat.codeGeneration.instructions":[{"text":"只需修改 ./script/ 目录下的文件,不修改其他目录下的文件."},{"text":"若目标代码文件行数超过 1000 行,建议将新增函数置于新文件中,通过引用调用;如产生的修改导致文件超长,可暂不严格遵守此规则."}],"github.copilot.chat.testGeneration.instructions":[{"text":"在现有单元测试文件中生成测试用例."},{"text":"代码修改后务必运行测试用例验证."}],

常见问题

输入需求得不到想要的业务代码

需要将大任务拆分成较小的任务, 每次会话只处理一个小任务. 这是由于大模型的上下文太多会导致注意力分散.

喂给单次对话的上下文, 需要自己揣摩, 太多和太少都会导致不理解需求.

DeepSeek 模型解决了注意力分散问题, 但需要在 cursor 中使用 Deepseek API. 不清楚其效果如何.

响应缓慢问题

需要理解 token 消耗机制, token 输入是便宜且耗时较短的, token 输出贵很多, 且明显更缓慢.

假如一个代码文件非常大, 实际需要修改的代码行只有三行, 但由于上下文多, 输出也多, 会导致 token 消耗很快, 且响应缓慢.

因此, 必须要考虑控制文件的大小, 不要写很大的文件和很大的函数. 及时拆分大文件, 大函数, 通过引用调用.

业务理解问题

理解问题或许有些依赖代码中的注释, 以及测试文件, 代码中补充足够的注释, 以及测试用例, 有助于 Copilot Agent 更好的理解业务.

Agent 自己生成的业务代码就有足够多的注释, 检视这些注释, 就可以快速判断 Agent 是否正确理解了需求.

生成大量代码需要 debug 较久

可以考虑在生成某个特性的基础代码后, 先生成测试用例, 再调整业务逻辑,这样 Agent 可以自行进行调试,自我验证.

Agent 会询问是否允许运行测试命令, 运行完成后会自行读终端输出, 以此来判断代码是否正确. 如果不正确, 会根据报错信息进行修改. 循环往复, 直到测试通过.

也就是需要自己更多理解业务, 需要手动写的时候并不太多, 如果测试用例代码和业务代码都不正确, Agent 既不能根据业务写出正确用例, 也不能根据用例写出正确业务代码, 这种情况才会出现 debug 较久的情况.

总结

理解大模型的 token 消耗机制, 输入的上下文很便宜,输出的代码较贵,文件中未修改的代码部分可能也算作输出, 证据是很多无需修改的代码也会缓慢输出.

因此应尽量控制单文件的大小, 可以在使用中感受 Agent 在处理大文件和小文件时, 响应速度上的差异, 这个差异是非常明显的.

Read more

人工智能大模型应用开发:从微调适配到场景落地

人工智能大模型应用开发:从微调适配到场景落地

一、人工智能大模型应用开发:从微调适配到场景落地 1.1 本章学习目标与重点 💡 掌握大模型应用开发的核心流程,包括模型选型、微调适配、功能封装、部署上线等关键环节; 💡 熟练运用主流大模型框架(Hugging Face Transformers、LangChain、LlamaIndex 等),实现文本生成、问答系统、智能助手等常见应用; 💡 理解大模型微调的核心技术(全参数微调、LoRA、QLoRA 等),能够根据数据规模和硬件资源选择合适的适配方案; 💡 通过真实场景案例(企业知识库问答、智能客服、代码生成助手),掌握大模型从技术适配到业务落地的端到端开发能力。 ⚠️ 重点关注:大模型的上下文窗口限制、生成内容的准确性与安全性、微调过程中的显存优化、以及生产环境下的性能与稳定性平衡。 1.2 大模型应用开发基础:选型与环境搭建 大模型应用开发的第一步是明确业务需求,选择合适的模型并搭建稳定的开发环境。本节将从模型选型原则、主流开发框架介绍、环境搭建实操三个维度,为后续开发奠定基础。 1.2.1

【AI】trae Skills使用方法

【AI】trae Skills使用方法

一、Skills是什么? Skill可以理解为agent的技能,Claude官方的解释是,使用 Skills 可以提升执行特定任务的能力。比如,可以在本地就能调用 Skills 玩转图片、Excel、Word、PDF 等处理操作,它和agent、mcp对比: 特性对比表格 特性SkillsSub-AgentsMCP (Model Context Protocol)目的用专业知识、工作流程、资源扩展 Claude生成自主代理处理复杂子任务连接外部工具和数据源调用方式模型自动发现(基于上下文)父代理显式生成MCP 服务器工具调用持久性触发时加载到上下文独立运行,返回结果无状态工具执行最适合领域专业知识、工作流程、模板并行任务、研究、探索外部 API、数据库、第三方服务上下文使用渐进式披露(元数据→指令→资源)每个子代理有独立上下文最小上下文(仅工具定义)复杂度低(只需 SKILL.md + 可选文件)中等(需要编排)中-高(

相干伊辛机在医疗领域及医疗AI领域的应用前景分析

相干伊辛机在医疗领域及医疗AI领域的应用前景分析

引言:当量子退火遇见精准医疗 21世纪的医疗健康领域正经历着一场由数据驱动的深刻变革。从基因组学到医学影像,从电子病历到可穿戴设备,医疗数据正以指数级增长。然而,海量数据的背后是经典的“组合爆炸”难题——例如,药物分子中电子的量子态搜索、多模态医疗影像的特征匹配、个性化治疗方案的组合优化等,这些问题对经典计算机,甚至对传统的超级计算机而言,都构成了难以逾越的计算壁垒。 相干伊辛机(Coherent Ising Machine, CIM)作为一种基于量子光学和量子退火原理的新型计算范式,为解决这类组合优化问题提供了全新的物理路径。它不同于通用量子计算机(如超导门模型),CIM是专为寻找复杂伊辛模型基态而设计的专用量子处理器。本文将深入探讨CIM如何凭借其强大的并行搜索能力,在药物研发、精准诊断、个性化治疗以及医疗AI优化等领域,从计算底层赋能医疗科技的未来。 一、 相干伊辛机:从统计物理到量子计算引擎 要理解CIM在医疗领域的潜力,首先需要深入其物理内核,厘清它如何通过光的相干性来高效解决现实世界的复杂问题。 1. 伊辛模型:组合优化的“通用语言” 伊辛模型最初源于统计物理学

OpenClaw 的免费 AI 大模型及其配置方法

OpenClaw 中的“自由模型”可能意味着两种不同的东西,而混淆这两种模型正是大多数人浪费时间的地方。 有一种“免费”是真正意义上的免费,因为模型运行在本地,你只需要支付 CPU、内存、GPU 和电力费用。例如 Ollama 或你自行托管的 OpenAI 兼容运行时环境。 另一种是“免费套餐”,即托管服务提供商提供一定的配额、积分或 OAuth 访问权限。这种套餐虽然不错,但通常会有速率限制、策略限制,而且偶尔还会出现意外中断或流量突然上限的情况。 本指南篇幅较长,因为模型配置看似简单,但一旦遇到问题,例如工具调用速度变慢、出现 429 错误,或者某个代理使用的身份验证配置文件与预期不符等,就会发现其中的奥妙。我们将力求实用。 如果您是 OpenClaw 新手,想先了解基础知识,可以阅读 OpenClaw 简介及其工作原理。如果您已经运行了 OpenClaw,接下来我们来正确地连接模型。 OpenClaw