113、【Agent】【OpenCode】项目配置（package.json）
【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】Skill 工具提示词
分析了最后一个工具 Skill，Skill 工具可以加载一个专门的技能，所谓的技能可以提供特定领域的指令和工作流，其唯一的必选参数name用来描述要加载的技能名称，其描述文本为动态加载，当list.length == 0时，也就是当前没有 Skill，OpenCode 客户端会告知当前没有可用技能，而当list.length > 0时，客户端就会拼接出一段结构严谨的说明文本，告知触发条件和预期结果，并遵循渐进式披露规则（只有当 AI 决定使用某个技能并真正调用 Skill 工具之后，详细的指令才会被注入进来，实现按需加载，否则只展示技能名字和简介），下面继续分析
OpenCode
之前 blog
【Agent】【OpenCode】源码构建（依赖安装）
【Agent】【OpenCode】源码构建（项目构建）
在分析源码构建的时候，略微有提到package.json，下面涉及到项目配置，来详细分析下这个文件
package.json是Node.js 和前端项目的身份证和核心配置文件（OpenCode 客户端相对于 AI 大模型来说，也可以理解为前端），该文件位于项目根目录，有如下作用
- 记录项目的基本信息：比如项目名称（name），版本号（version），作者，入口文件
index.js（main）等元数据信息
管理依赖包（最核心的功能之一）：把项目需要的第三方库分类地记录下来，防止生产环境误装开发工具，有两种依赖类型
dependencies（生产依赖）：项目运行时必须的包，部署上线时也要带上devDependencies（开发依赖）：只在本地开发和构建阶段用的工具，上线时不需要- 配置快捷脚本命令（scripts）：可以把复杂的命令行操作变成一键执行的快捷方式，比如在里面配置了
bun run script/build.ts，后面在终端里只需要输入bun run build就能完成打包工作，不用再输入一长串命令 - 提供其他工程化配置：很多现代前端工具也会把自定义配置直接写在里面，比如浏览器兼容范围（browserlist），ESLint 规则（eslintConfig）等
新建项目的时候，在终端运行npm init（会一步步问问题），或者npm init -y（直接跳过问答，用默认配置生成），就能自动创建一个基础的package.json骨架
另外，package.json既可以由开发者手动更新，也会被包管理器（比如npm，bun等）自动更新，开发者可能会发现在执行bun install时，package.json被 modified 修改了，这就是因为 Bun 在整理或规范化这个文件：
- 开发者手动更新：可以直接用编辑器打开，添加依赖，修改版本号或者编写脚本
- 命令行自动更新：当执行类似
bun add或者npm install等命令时，包管理器会自动把新包写入dependencies字段中
单纯运行bun install（没有指定新包），理论上来说应该去读取依赖并安装，如果发现package.json还是被改了，大概原因是因为JSON 格式化与键值排序，比如
Bun 作为一个追求极致性能和高标准的现代工具，在读取package.json后，会按照自己内部的规范对 JOSN 结构进行重新排版，比如把dependencies里的包名按字母顺序重新排列，或者调整某些字段的先后顺序，这种操作不会改变项目的实际逻辑，但在 Git 看来，文件内容确实发生了变化
最后再提醒下，虽然package.json可以手动修改，但项目中另一个伴随文件（对 Bun 来说是bun.lock，对 Npm 来说是package-lock.json）是绝对禁止修改的，这俩文件是共生协作的关系
package.json定义了项目允许安装的版本范围（提供灵活性）- Lock 文件则锁定了实际安装的精确版本和依赖树，确保团队环境的一致性
所以 Bun 在后台做的那些代码格式化或结构优化，只要程序能正常构建运行，这种修改是无害的，如果觉得这种 Git 报的 modified 变动看不过去，可以在确认无误后直接提交
OK，本篇先，到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】项目配置（package.json 和 bun.lock）