Files
HomeAgent/internal/agent/core/toolerror.go
JianFeeeee 6d38a164eb chore(module): Go module 路径随托管地迁移 gitcode → github
## 背景

仓库早已迁移到 GitHub(`github.com/JianFeeeee/HomeAgent`,CI/CD 都在那边跑),
gitcode 保留为**国内只读镜像**(`ci.yml` 的 sync-gitcode-main 快进推送)。
但 go.mod 的 module 路径一直是 `gitcode.com/JianFeeeee/...` —— 既与权威源
不符,`meta.SourceURL`(AGPL §13 的源码提供入口)也指向镜像而非实际运行的代码。

## 关键区分(这是本次改动安全的前提)

两个 module 是**不同**的,影响面差一个数量级:

| module | 谁依赖 | 改它的后果 |
|---|---|---|
| `.../HomeAgent`(主仓) | **只有主仓自己** | 内部重构,零外部影响 |
| `.../homeagent-sdk`(SDK 仓) | 主仓 49 文件 + 所有外部插件 | 需重编插件 |

★ 实测确认:**插件不 import 主仓 module**(`strings qq/plugin.bin | grep HomeAgent` = 0),
只依赖 SDK 仓。而插件与内核的边界是 **RPC 方法名字符串**
(`plugin.init` / `tool.invoke`…,见 proc/protocol.go),**与 Go module 名无关**。
⇒ module 改名**不改变任何 wire 协议**,现网已装的插件照常运行。

SDK 的 GitHub 仓名是 `homeagentsdk`(无连字符),module 路径必须与之精确匹配,
否则 `go get` 会因路径不符失败,故取 `github.com/JianFeeeee/homeagentsdk`。

## 改动

- `go.mod` / `go.sum`:两个 module 路径 + require/replace
- 277 个 Go 文件 + Makefile + 打包脚本的 import 与 ldflags 路径
- SDK 仓 `meta.CoreModule`、`tools/hmapdev` 的 module 声明与工程模板
- 对外文档/链接的仓库地址(README、PLUGIN_DEV、OVERVIEW 等)

## 明确**保留** gitcode 的地方(镜像机制,不能动)

- `GITCODE_TOKEN`、`GC_URL="…@gitcode.com"`(CI 同步 job)
- `gitcode.com/api/v5/...`(release 附件上传)
- git remote `gitcode`(镜像拉取/推送)
- `docs/zh/ci-cd-runbook.md`(整篇讲镜像运维)

## 验证

- `go build ./...` / `go vet ./...` 绿
- `go test ./... -count=1` → 48 包 ok / 0 FAIL
- hmapdev 工具链编译通过(`third_party/homeagent-sdk/tools/hmapdev`)
- 全仓残留检查:module 形态的 `gitcode.com/JianFeeeee` = 0
- 镜像机制抽验:GC_URL / @gitcode / api/v5 / remote 均完好

## 顺带修正

`hmapdev/templates.go` 的注释此前写「gitcode 的模块不在 proxy.golang.org 上」——
module 已迁 GitHub,该论断不再成立。改为如实说明**为何仍默认 replace 到本机 SDK**:
离线可构建、避免版本漂移、内网可用。理由与托管地无关,故 replace 保留。
2026-10-08 10:40:17 +08:00

155 lines
4.8 KiB
Go
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

package core
import (
"encoding/json"
"fmt"
"strings"
sdk "github.com/JianFeeeee/HomeAgent/internal/sdk"
)
// 工具失败原因码(与 SDK 的 ToolError.Reason 对应)。
const (
ErrReasonRequired = "required"
ErrReasonType = "type"
ErrReasonUnauthorized = "unauthorized"
ErrReasonTimeout = "timeout"
ErrReasonNotFound = "not_found"
)
// newToolError 构造一个结构化失败。
func newToolError(reason, field, detail, hint string) *sdk.ToolError {
return &sdk.ToolError{Reason: reason, Field: field, Detail: detail, Hint: hint}
}
// isToolError 报告一个工具返回值是否表示**失败**。
//
// 存在的理由:工具失败是以 `nil` error + 错误**值**返回的,而
// ToolResult.Success 此前被硬编码为 true(唯一赋值点),该字段恒真、
// 结构上不可能为 false。
//
// ⚠️ 判据必须兼容**既有三种约定**(实测于仓内,否则升级会把存量插件
// 的成功误判成失败——这是本函数最大的回归风险):
//
// ① {"error": msg} pluginmgr、cmd 的参数校验
// ② {"isError": true, "content": msg} files / clawhubadapter 的 errorResult
// ③ *sdk.ToolError 新写的工具(可选,不是迁移要求)
//
// 明确**不**作为失败判据的:
// - exit_code != 0:命令跑了但返回非零,属业务结果且带真实 stdout/stderr,
// 整条判失败会误伤「命令可用但结果非零」这类正常场景。
// - stderr 非空:cmd 成功路径常带 stderr(如 warn: deprecated)。
// - 字符串 / 数字 / bool / 数组 / nil:均视为成功(output_send 成功即返回 "ok")。
func isToolError(v interface{}) bool {
switch x := v.(type) {
case nil:
return false
case *sdk.ToolError:
return x != nil
case sdk.ToolError:
return true
case error:
// 工具显式返回 error —— 失败。
return x != nil
case map[string]interface{}:
// ② isError 优先:显式布尔标记,语义最明确。
if b, ok := x["isError"].(bool); ok && b {
return true
}
// ① error 键:非空字符串才算失败。
if e, ok := x["error"]; ok {
switch ev := e.(type) {
case string:
return strings.TrimSpace(ev) != ""
case nil:
return false
default:
// error 是结构化值(如嵌套的 ToolError)—— 视为失败。
return true
}
}
return false
case string:
// 自由文本无法可靠判别成败,按**成功**处理(保守:宁可少报失败,
// 也不要把正常结果报成失败)。失败请用上面三种显式形态。
return false
default:
return false
}
}
// toolErrorText 把一个失败返回值渲染成给模型看的文本。
// 结构化 ToolError 会带上 Hint——这是「让模型看得懂真因」的关键。
func toolErrorText(toolName string, v interface{}) string {
switch x := v.(type) {
case *sdk.ToolError:
return renderToolError(toolName, x)
case sdk.ToolError:
return renderToolError(toolName, &x)
case map[string]interface{}:
if b, ok := x["isError"].(bool); ok && b {
msg, _ := x["content"].(string)
if msg == "" {
msg = "(插件未给出原因)"
}
return fmt.Sprintf("工具 %s 失败: %s", toolName, msg)
}
if e, ok := x["error"]; ok {
if s, ok := e.(string); ok {
return fmt.Sprintf("工具 %s 失败: %s", toolName, s)
}
}
case error:
return fmt.Sprintf("工具 %s 失败: %v", toolName, x)
}
return fmt.Sprintf("工具 %s 失败: %v", toolName, v)
}
// renderToolError 渲染结构化失败:把 field/reason/hint 都摆出来,
// 让模型知道**该改什么**,而不是只知道「失败了」。
func renderToolError(toolName string, e *sdk.ToolError) string {
var sb strings.Builder
fmt.Fprintf(&sb, "工具 %s 失败", toolName)
if e.Field != "" {
fmt.Fprintf(&sb, "(字段 %s)", e.Field)
}
sb.WriteString(": ")
if e.Reason != "" {
sb.WriteString(e.Reason)
}
if e.Detail != "" {
sb.WriteString(" — ")
sb.WriteString(e.Detail)
}
if e.Hint != "" {
sb.WriteString("\n请据此修正后重试:")
sb.WriteString(e.Hint)
}
return sb.String()
}
// renderToolResult 把工具返回值渲染成给模型看的文本。
//
// 规则:**结构化失败优先**——失败必须带上可执行信息(字段/原因/Hint),
// 而不是退化成 `map[error:xxx]` 这种模型读不懂的 Go 语法。
// 成功则用紧凑 JSON(绝不用 fmt.Sprintf("%v"),那会产出 Go 的 map 语法)。
func renderToolResult(toolName string, raw interface{}) string {
if raw == nil {
return ""
}
if isToolError(raw) {
return toolErrorText(toolName, raw)
}
switch x := raw.(type) {
case string:
return x
case error:
return fmt.Sprintf("%v", x)
}
// 非字符串:紧凑 JSON。
if b, err := json.Marshal(raw); err == nil {
return string(b)
}
return fmt.Sprintf("%v", raw)
}