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

【大模型教程——第二部分:Transformer架构揭秘】第1章:Transformer核心揭秘 (The Transformer Architecture)【上】

第1章:Transformer核心揭秘 (The Transformer Architecture) “Attention is all you need.” - Vaswani et al., 2017 重要提示:本章是全书中唯一详细讲解Transformer架构的章节。后续章节将直接引用本章内容,不再重复讲解核心机制。 本章将带你深入Transformer的每一个核心组件,从数学原理到代码实现,从直觉理解到工程优化。掌握了这些,你就掌握了现代大语言模型的基石。 目录 * 一、宏观蓝图:编码器-解码器架构 * 原始Transformer:翻译机器的设计 * 1. 编码器(Encoder):理解输入 * 2. 解码器(Decoder):生成输出 * 3. 信息流动:编码器到解码器 * 现代简化:为何只用编码器或解码器? * 二、核心组件一:自注意力机制(Self-Attention) * 1. 为什么需要自注意力?从一个问题开始

仿生新势力:Openclaw开源仿生爪,如何革新机器人抓取?

仿生新势力:Openclaw开源仿生爪,如何革新机器人抓取?

仿生新势力:Openclaw开源仿生爪,如何革新机器人抓取? 引言 在仓储、农业乃至家庭服务中,机器人如何像猫一样灵巧、自适应地抓取千变万化的物体?这曾是行业难题。如今,一个名为 Openclaw 的开源仿生机械爪项目,正以其独特的被动适应性设计和亲民的成本,在机器人末端执行器领域掀起波澜。本文将深入解析Openclaw的仿生奥秘、实现原理、应用场景及未来布局,带你全面了解这款来自开源社区的“仿生新势力”。 一、 核心揭秘:从猫爪到机械爪的实现原理 本节将拆解Openclaw如何将生物灵感转化为工程现实。 1. 仿生学设计理念 Openclaw的核心灵感源于猫科动物爪部。当猫抓取物体时,其爪趾会自然地包裹贴合物体表面,这种能力主要依赖于其肌腱和骨骼的被动结构,而非大脑的实时精密控制。Openclaw借鉴了这一思想,核心是被动适应性机制。它无需依赖复杂的传感器反馈和实时力控算法,仅凭精巧的机械结构即可根据物体形状自动调整接触点和抓取力,从而极大地简化了控制系统。 配图建议:猫爪与Openclaw的对比图,或Openclaw抓取不同形状物体的动态示意图。 2. 欠驱动与

OpenClaw 钉钉群聊多机器人配置完全指南

OpenClaw 钉钉群聊多机器人配置完全指南

OpenClaw 钉钉群聊多机器人配置完全指南 在团队协作中,配置多个专用机器人可以显著提升工作效率——不同的机器人可以分别负责写作、编码、数据分析等不同任务。本文将详细介绍如何在使用OpenClaw的钉钉群聊中配置多个任务机器人,并进一步讲解如何为每个机器人赋予独特的性格和工作规范。 一、钉钉端配置 首先,我们需要在钉钉开放平台创建多个任务机器人。 1.1 创建机器人 1. 按照上述步骤,根据实际需求创建多个机器人。 机器人创建完成后,务必记下 Client ID 和 Client Secret,这些信息后续配置会用到。 访问 钉钉开发者平台,点击立即创建按钮创建任务机器人。 二、OpenClaw端配置 完成钉钉端的配置后,接下来我们在OpenClaw中进行相应的设置(默认已装过钉钉插件)。 # 安装钉钉渠道插件 openclaw plugins install @dingtalk-real-ai/dingtalk-connector # 重启 gateway openclaw gateway restart 2.1 添加 Agent

# OpenClaw QQ 机器人接入完整指南

作者: 星期五助手 创建时间: 2026-03-05 适用版本: OpenClaw 2026.2.26+ 📖 目录 1. 项目概述 2. 环境准备 3. 安装 NapCat QQ 机器人 4. 配置 OpenClaw QQ 插件 5. 网络配置(关键) 6. 测试与验证 7. 常见问题 项目概述 本指南介绍如何将 OpenClaw 接入 QQ,实现通过 QQ 与 OpenClaw 智能助手对话。 架构说明 ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │ QQ 用户 │ ──→ │ NapCat │ ──→ │ OpenClaw │ │ (发消息) │ │ (QQ 机器人) │ │ (星期五)