图解AI编程（Go版）

第14章 知道边界在哪，比知道怎么做更难 ​

前13章你学会了怎么造Agent——脑子、手脚、记忆、规划、安全、部署。但还有一个比技术更重要的问题：Agent能做什么，不能做什么？做错了谁负责？这一章可能是全书"最不技术"的一章，但可能是对你影响最深远的一章。

14.1 Agent能做什么？不能做什么？ ​

14.1.1 Agent的能力边界 ​

不要把Agent当万能药。它有以下明确的能力边界：

能做的事：

能力例子
理解模糊指令"帮我安排一个轻松点的周末"
调用外部工具查API、调数据库、发邮件
多步骤推理"先查天气，再推荐穿搭"
处理非结构化数据读PDF、解析聊天记录
模式识别"这些评论都在抱怨物流"

不能（或不该）做的事：

限制原因
做精确数学计算LLM是语言模型，不是计算器
保证100%正确幻觉问题目前无解
替代人类判断没有情感、没有价值观
创造性突破能重组已有的知识，不能发明
处理超出训练数据的事不知道今天的新闻、你公司的秘密

14.1.2 Go开发者的特殊思考 ​

Go开发者在Agent设计上有一种天然的谨慎——因为Go的哲学本身就是"简单、可靠"。你在Go项目里不会用一个"看起来能跑"但内部机制不透明的库。对Agent也应该一样：

go
// ✅ Go的风格：明确的能力声明
type AgentCapabilities struct {
    CanSearchWeb    bool
    CanAccessDB     bool
    CanSendEmail    bool
    CanDeleteData   bool
    MaxTokensPerReq int
}

// ❌ 不Go的风格：模糊的全能Agent
// "它能做任何事" —— 这不是Go的哲学

14.2 Agent也会"胡说八道"，怎么验证事实？ ​

14.2.1 幻觉是无法根除的 ​

LLM的"幻觉"（生成看似合理但完全错误的内容）是架构性问题，不是bug。它就是一个接话机器——它不"知道"真假，只知道"接什么话最自然"。

能做的不是消除幻觉，而是降低幻觉的影响：

  1. 用RAG绑定真实数据源（第7章）
  2. 关键数据用工具验证，不信LLM的"记忆"
  3. 给用户的回复加置信度标注
  4. 高风险场景（医疗、法律、金融）设人工审核环节

14.2.2 验证链路 ​

go
func (a *Agent) answerWithVerification(ctx context.Context, 
    question string) string {
    
    // 1. 生成回答
    answer := a.generate(ctx, question)
    
    // 2. 涉及数据 → 调工具验证
    if requiresFactCheck(answer) {
        facts := a.verifyFacts(ctx, answer)
        if !facts.Verified {
            return "抱歉，我查到的信息和我的回答不一致，" +
                   "以下是核实后的结果：" + facts.Corrected
        }
    }
    
    // 3. 返回（带标注）
    if answer.Confidence < 0.7 {
        return answer.Content + "\n\n⚠️ 以上回答仅供参考，建议核实。"
    }
    return answer.Content
}

14.3 Agent做错了事，谁负责？ ​

14.3.1 这不是技术问题，但你必须想 ​

假设你的Agent帮用户订了一张机票。它订错了日期。用户误了会议，损失了一个大客户。

谁负责？

  • Agent？它是软件，没有法律责任主体。
  • LLM提供商？他们条款里写着"不保证准确性"。
  • 你（开发者）？你写的Agent，你部署的。
  • 用户？他确认了错误的信息。

答案是模糊的。目前法律没有明确界定。但有几条原则你可以在设计时就考虑：

  1. 高风险操作永远要人工确认
  2. 保留完整的决策日志（谁在什么时间做了什么决定）
  3. Agent说的话不要包装成"权威"—加免责声明
go
// 决策审计日志
type DecisionLog struct {
    Timestamp   time.Time
    UserID      string
    AgentAction string
    Reason      string
    ToolCalls   []ToolCallRecord
    UserConfirmed bool
}

// 每次Agent执行写操作，都记录
func (a *Agent) logDecision(ctx context.Context, 
    action string, result interface{}) {
    db.Create(&DecisionLog{
        Timestamp:   time.Now(),
        AgentAction: action,
        Reason:      extractReason(result),
        ToolCalls:   getToolTraces(ctx),
    })
}

14.4 你的下一个同事，可能是Agent ​

14.4.1 不是替代人，是改变工作方式 ​

历史上每次技术变革，恐慌的论调都一样："机器要取代人了"。

纺织机没让裁缝消失——裁缝变成了服装设计师。ATM没让银行柜员消失——柜员变成了理财顾问。

Agent也一样。它不会让程序员消失，但会让只会写CRUD的程序员越来越不值钱。会设计Agent系统、会定义工具接口、会规划工作流的开发者，会越来越贵。

14.4.2 未来已来 ​

这不是空话。2025-2026年的趋势已经很清楚了：

  • AI写代码从"玩具"变成了"效率工具"
  • Agent从"概念"变成了"产品"
  • 招聘JD里"AI Agent开发经验"从"加分项"变成了"优先项"

你学完这本书的时候，已经在这条路上走了15章。你不是在追赶趋势，你已经在趋势里了。

14.5 本章小结 ​

这一章没有代码，但比有代码的章节更重要：

  1. Agent的能力边界：能理解模糊指令，但不能保证100%正确。Go开发者的谨慎是天生的优势。
  2. 幻觉无法根除：能做的是降低影响。RAG绑定数据源 + 工具验证 + 置信度标注。
  3. 责任归属模糊：高风险操作永远要人工确认。保留完整的决策审计日志。
  4. Agent是同事，不是替代者：改变的是工作方式，不是工作本身。

✅ 知识点检查 ​

学完这一章，试试思考这几个问题：

  • [ ] Agent最不适合做的三类事情是什么？
  • [ ] 如何降低LLM幻觉的影响？
  • [ ] 为什么高风险操作需要人工确认？
  • [ ] 你觉得Agent会让你失业吗？为什么？

📚 延伸阅读 ​

🎯 下一章预告 ​

第15章，恭喜，你不只会写Agent了——

"没有'最好'，只有'最合适'。你的Agent之旅才刚刚开始。"