AI Agent 架构落地先做任务边界再谈自主智能一、Agent 最容易被讲成玄学很多团队一听 Agent就想到“让大模型自己规划、自己调用工具、自己完成任务”。这个方向没错但如果一开始就追求自主智能很容易做成一个不可控的黑盒。真正落地时我更关心三个问题它能处理哪类任务能调用哪些工具出了错谁兜底。Agent 不是聊天机器人换个名字。它的关键区别是能做动作。只要系统能做动作就必须先定义边界。比如查询知识库是低风险创建工单是中风险发送邮件或执行脚本就是高风险。风险不同确认和审计策略也不同。二、落地链路从目标到可控执行在实际项目中我见过太多团队把 Agent 设计成一个全能助手结果上线后问题不断用户让它查数据它顺手发了邮件让它生成报告它调用了删除接口。问题不在模型能力而在链路设计。flowchart TD A[用户目标] -- B[任务分类] B -- C[生成执行计划] C -- D[权限与风险检查] D -- E[工具调用] E -- F[结果校验] F -- G[返回结论或请求确认]这条链路看起来比模型自己跑麻烦但生产系统就该麻烦在该麻烦的地方。计划可以让模型生成风险判断和执行权限不能只靠模型自觉。工程系统要把刹车装在代码里。任务分类的实战经验在我们的系统中我们把任务分为三个等级L1 只读任务查询知识库、读取配置、生成报告自动执行L2 写操作任务创建工单、更新数据、发送通知需确认L3 高风险任务执行脚本、删除资源、修改权限需二次确认审计分类不是一成不变的。比如发送邮件在测试环境是 L2在生产环境可能涉及客户通知就升级为 L3。这种分级让我们在保持自动化效率的同时把风险控制住。三、代码示例给工具调用加风险等级package agent type ToolRisk string const ( RiskRead ToolRisk read RiskWrite ToolRisk write RiskExec ToolRisk exec ) type ToolCall struct { Name string Risk ToolRisk Args map[string]any } func NeedConfirm(call ToolCall) bool { return call.Risk RiskWrite || call.Risk RiskExec }这段代码不复杂但表达了一个很重要的原则工具不是平等的。只读工具可以自动化多一些写操作和执行类工具必须更保守。很多 Agent 事故不是模型不会推理而是系统没有区分动作风险。生产级改进在实际项目中我们还需要考虑更细粒度的权限控制。比如同样是写操作创建草稿和发布文章风险不同同样是读操作读取公开数据和读取用户隐私权限不同。我们扩展了上面的代码package agent // 增加风险子类型和用户权限 type ToolCall struct { Name string Risk ToolRisk Resource string // 操作的资源类型 UserRoles []string // 用户角色 } // 检查用户是否有权限执行此工具调用 func (t ToolCall) HasPermission() bool { // 读取类操作需要基础权限 if t.Risk RiskRead { return hasRole(t.UserRoles, reader) } // 写入类操作需要写入权限 if t.Risk RiskWrite { return hasRole(t.UserRoles, writer) } // 执行类操作需要管理员权限 return hasRole(t.UserRoles, admin) }这个改进让权限控制更加精细化。我们在一个实际项目中应用后成功阻止了一次普通用户试图通过 Agent 删除其他用户数据的尝试。四、工程边界Agent 要有成本和步数上限Agent 还要有预算。一次任务最多调用几次模型、最多调用几个工具、最多运行多长时间都要写清楚。没有上限的 Agent会在复杂任务里循环尝试最后烧掉 token、拖慢队列还给不出可靠结果。达到上限时系统应该返回当前进度、失败原因和下一步建议。实战踩坑记录我们第一个 Agent 版本没有步数限制结果遇到一个边界 case用户问帮我分析过去一年的销售趋势并预测下季度Agent 生成了一个包含 50 步骤的计划每个步骤都调用模型分析数据结果跑了 15 分钟消耗了 30 万 token最后超时失败。用户投诉比手动做还慢。改进后我们加了三层限制步数上限单次任务最多 10 步时间上限单次任务最多 3 分钟Token 预算单次任务最多 1 万 token超出限制时Agent 会返回任务较复杂我已完成了 X 步共计划 Y 步包括1) 已完成的步骤... 2) 当前进度... 建议您可以让我继续完成剩余步骤或者我可以先展示已完成的部分。取舍方面自动化越强确认越少体验越顺但风险也越高。我的做法是按任务价值分层低风险任务自动跑高风险任务给用户看计划和影响范围。用户不是要看模型思考过程而是要知道系统将访问什么、修改什么、能不能撤销。可观测性也不能省。每一次工具调用都应该记录 request_id、工具名、参数摘要、权限结果、耗时和错误类型。不要记录敏感明文但要能复盘链路。Agent 系统如果不可观测排障会比普通后端更痛苦。实战数据我们在生产环境部署 Agent 三个月收集了一些有意思的数据有步数限制后任务完成率从 62% 提升到 89%Token 消耗降低 47%主要来自避免无限循环用户满意度从 3.2 提升到 4.15分制还有一个容易被忽略的点Agent 的计划要能被用户和系统共同理解。不要只保存模型的一段自然语言思考而要保存结构化步骤、依赖关系和每步状态。这样失败时可以从中间恢复也可以让用户知道是卡在权限、工具还是数据不足。生产 Agent 不是一次性聊天而是一条可追踪任务流。评测也要按任务类型拆开。知识查询看引用准确率工具执行看参数正确率长任务看完成率和中断恢复高风险任务看确认流程是否清楚。把所有任务混成一个满意度很难指导优化。边界清楚评测才有意义。五、总结AI Agent 架构落地先做任务边界、风险分级、权限校验、预算控制和可观测性再谈自主智能。Agent 能做事系统就必须能解释、能停止、能兜底。