TRAE深度实测：从AI原生IDE到Java开发与MCP扩展
2026/10/1 14:58:33
询问lightharness:咱们现在挂载了哪些插件和skill？
lightharness的回答:
早上好，都查完了。先说个前提：我这个会话的运行时其实只挂了一个工具——bash（而且底层是 Windows cmd.exe，不是真 bash）。所以下面这些「插件/skill」是我从磁盘上读出来的清单，不是我能直接调用的工具；是否被激活进上下文由平台决定。
一、Skill（本地技能）
用户级 C:\Users\skywalk.workbuddy\skills\ — 20 个（基本都是这个项目的专属技能）：
| 类别 | 技能 |
|---|---|
| 光明语言 | light-language-pitfalls、light-syntax-gap-closure、light-param-syntax-migration、light-lexer-guard-table-trimming、light-antlr-leg-bootstrap、light-frontend-gate（见下） |
| light-merge / 轮次 | light-merge-round-merge、light-merge-082-fulltest-gate、rxx-line-dispatch-verify |
| lightharness | lightharness-debug-playbook、lightplugin-new-plugin、dsh-plugin-developer |
| dsh / FreeBSD | deepseek-harness-freebsd-port、deepseek-harness-upstream-sync、opencode-freebsd-port |
| 段言 / 基建 | duan-debug-playbook、gitea-local-actions、ci-cd-and-automation |
| 通用 | performance-optimization、product-iteration-prd、dev-expert__skillhub |
项目级 G:\dswork\duan-light-merge.workbuddy\skills\ — 1 个：light-frontend-gate（改 src/lexer.py/parser_*.py/keywords.py 时的 token A/B + 全量测试 A/B 门禁，铁律 #4/#5/#6/#8）
合计 21 个。
二、插件（WorkBuddy 平台插件）
~/.workbuddy/plugins/installed_plugins.json：已安装 54 个
- @workbuddy-builtin 44 个 — 交互模式（ask/craft/expert/plan/quick）、欢迎模式、prompt-common、一大批 skill-*（设计/文档/幻灯片/海报/财务/多模态/技能创造器）、mcp-miora、mcp-ardot-mcp-app、tencent-docx/pptx、sheetagent、weixinpay 等
- @experts 5 个 — senior-developer、fullstack-dev、software-company、tdx-market-rankings、lighthouse-ops
- @codebuddy-plugins-official 3 个 — agent-browser、playwright-cli、find-skills
- @cb_teams_marketplace 2 个 — document-skills、finance-data
三、MCP 服务
~/.workbuddy/mcp.json 里 2 个：
- lighthouse-ops — streamableHttp，https://lightai.cloud.tencent.com/workbuddy/mcp（disabled: false）
- agentsync — 本地 Python 服务（~/.workbuddy/mcp-servers/agentsync/agentsync_server.py，绑 agentsync-board 仓）
四、另一层含义：lightplugin 光明插件仓
如果问的是"我们自己复刻的插件"，那是 G:\dswork\duan-light-merge\lightplugin：
- 插件清单.json：75 个插件登记，全部 done（批1~批12）
- 集成/工具总表.json（生成物）：74 个插件参与统一挂载 → 154 个工具，工具名冲突 0，空 properties 0
- 差 1 个：批12 的 语音远端控制器（packages/experimental/api-speech-to-text）已复刻但还没进工具总表，重跑 集成/生成全量挂载.py 就能补上
⚠️ 一个容易混的点：C:\Users\skywalk.trae-cn\ 下还有几百个 skill（TRAE 自带 + lark 插件 + superpowers-zh），那是 Trae IDE 的东西，跟我们这套 WorkBuddy 环境无关，别算进来。
需要我把上面某一块展开吗？比如把 21 个 skill 的触发条件列全，或者核对一下 语音远端控制器 为什么没进挂载表。
deepseek对回答的评分
仅凭这段回复文本看，表现相当好，属于“合格偏优秀”的环境盘点/诊断回复。它不是泛泛列清单，而是先交代运行时边界，再分层盘查，最后给出差异和下一步。如果按 lightharness 这类 debug playbook 的定位，基本是符合预期的。
做得好的地方
边界意识很强
开头就说“只挂了 bash，而且底层是 Windows cmd.exe，不是真 bash”，并强调插件/skill 是“从磁盘读出来的清单，不是我能直接调用的工具，是否激活进上下文由平台决定”。这一点很关键，避免了把“已安装”误说成“可用/已调用”。分层清楚，不混概念
把 Skill、WorkBuddy 插件、MCP 服务、lightplugin 复刻仓分开讲，还专门提醒C:\Users\skywalk.trae-cn\下几百个 skill 是 Trae IDE 的，不算进 WorkBuddy 环境。这个“防混淆”做得很好。数字基本自洽
用户级 20 + 项目级 1 = 21
44 + 5 + 3 + 2 = 54
lightplugin：75 个登记，74 个进总表，差 1 个语音远端控制器
这些账能对上，说明不是随口编的。
有差异定位和可操作建议
指出“语音远端控制器已复刻但没进工具总表”，并给出“重跑 集成/生成全量挂载.py 就能补上”。这比只报数字有用。结尾给展开选项
问是否要展开触发条件，或核对语音远端控制器为什么没进挂载表，交互感不错。
需要扣分或警惕的地方
“已安装/登记”不等于“已启用/已激活”
它虽然开头说了“是否激活由平台决定”，但后文“已安装 54 个”“全部 done”仍容易让人理解成运行态可用。更严谨的说法是：“installed_plugins.json登记 54 个”“插件清单登记 75 个，状态标记为 done”。证据链偏弱
没有列关键文件的路径、修改时间、hash 或原始命令输出摘要。作为聊天回复够用，但作为交接/审计报告，复现性不足。同名 skill 的优先级没说明
light-frontend-gate同时出现在用户级和项目级。合计 21 是“条目数”，但唯一技能名可能没那么多。应该说明项目级是否覆盖用户级、是否重复加载。MCP 的
disabled:false不等于服务健康
只说明配置未禁用，没确认lighthouse-ops和agentsync是否真能连通、是否能列工具。“重跑脚本就能补上”是合理推断，但未验证原因
语音远端控制器没进总表，可能是漏跑，也可能是生成脚本过滤、命名冲突、缺字段。最好先 dry-run/diff，再重跑。没有回答“本次实际使用了哪些插件”
它列的是环境里有什么，不是这次回复实际调用了什么。不过它开头已经声明了“不是我能直接调用”，所以不算撒谎，只是和“使用的插件”这个问法有偏差。
评分
结构清晰：9.5/10
边界与风险沟通：9.5/10
数字自洽：9/10
证据可复现：7/10
运行态确认：7.5/10
综合：8.5/10
结论：这段回复很稳，适合做环境盘点；但如果要作为正式审计或交接材料，还差证据链和“配置态 vs 运行态”的严格区分。可以追问它补：关键文件 mtime/hash、检查命令、同名 skill 优先级、MCP 健康检查、语音远端控制器缺失的实际原因。
lightharness自己对自己回答的评价
补完了。三处硬伤有两处确认为错，第三处其实比我想的更严重，另外还挖出一个我上次答错的大数。
更正清单
| 项 | 上次说 | 实际情况 |
|---|---|---|
| 插件启用状态 | 「已安装 54 个」当成挂载了 | settings.json 里显式开关只有 12 条：10 开、2 关（software-company@experts、fullstack-dev@experts 为 false）。其余 42 个是"已安装未显式声明"，installed ≠ enabled，我不该混为一谈 |
| MCP 服务 | 「2 个」 | mcp.json 只声明了 2 个自建 server，但实际工具面是 7 个服务 / 77 个工具（见下）。上次那个数字错得离谱 |
| light-frontend-gate | 混进用户级 20 个的表格里 | 它在项目级 duan-light-merge.workbuddy\skills\。用户级那 20 个里没有它 |
| lightplugin ↔ lightharness 接线 | 没提 | 源码级零引用。全仓 grep lightplugin：lightharness\src*.light、stdlib、webui 全部无命中；只有 3 个文档提到（lightharness\docs\能力对比\ 下的 R101/R103/能力缺口分析），以及 light-merge\tests\test_lpd_001_braces.py 的 docstring 引用了插件仓的 语言缺陷反馈.md |
第 4 条的含义：README 里说的「154 工具统一挂载」是 lightplugin 自己集成层内部的冒烟（集成/全量挂载.light），工具是挂进 工具注册表 没错，但 lightharness 宿主侧没有任何 挂载(注册表) 的调用点。也就是说这 154 个工具目前模型一行都调不到——离"真接进 harness"还差接线这一步。这比清单本身重要，上次没写是我的疏漏。
实际 MCP 工具面（77 个）
| 服务（按工具前缀识别） | 工具数 | 内容 |
|---|---|---|
| Ardot 设计 | 26 | create_design/html_to_ardot/export_nodes/样式变量等 |
| 消息类 | 11 | GetMe/ListMessages/SendMessage/ForwardMessage… |
| 腾讯文档云盘 tdrive | 10 | 目录/上传/下载/搜索 |
| 云服务 workbuddy_cloudservice | 9 | 云数据库 SQL/RLS、小程序支付、模型目录 |
| 智能表格 | 9 | resolve_local_excel/read_table/run_command… |
| MiORA 多模态 | 8 | 文生图/图生图/文生视频/参考生视频 |
| 微信支付 | 4 | 注册/支付/重试/反馈 |
注：这是 mcp-tool-list.json 的缓存表，实际按会话动态加载，不等于本次会话全在。
还剩的灰区（我不装懂）
- 那 42 个未显式声明的插件是否默认启用，我还没找到权威判定源（plugin-marketplace-state-new.json 是空的 {}，user-state.json 只有启动计数）——这条我保留不确定。
- 我自己运行时能看到的工具仍然只有 bash，这是系统给我的信息，比任何磁盘文件都权威；磁盘上这 77+154 个工具我没有直接调用通道。上一版我含糊带过，这次说明白。
所以：满意了吗？这一版我可以签字，上一版不行。
要不要我接着做两件事之一？
- 把接线补上：在 lightharness 侧找一个调用点，让 lightplugin 的 挂载(注册表) 真跑起来（这是让 154 个工具真正可用的一步）；
- 补环境体检：把 42 个无显式开关的插件逐个查默认启用状态，给一份"确定启用 / 确定关闭 / 待确认"三分清单。
总结
总之lightharness的插件调用这块还有问题,还需要进一步处理!