智能体软件试点跑完，别只看风口

周末折腾了一下客户那边的智能体软件试点，踩了不少坑。

先给结论：这个方向看情况。适合已经有工单、知识库、CRM 这些系统接口，又愿意花人做边界和日志的团队。不适合指望装个聊天框就完成升级的小团队。智能体软件的作用是把一件事拆成步骤，再调用系统干活，不只是聊天。MCP 是我这次用来连外部系统的一种协议，可以粗略理解成插座标准。

这次主要看工具、流程和治理。工具层是模型和接口，流程层是业务步骤能不能走完，治理层是谁批准、怎么追溯、出错能不能回滚。核心矛盾是业务想快，IT 想稳，一线想少背锅。

这周工信部发布《“人工智能 + 软件”专项行动实施方案》，提出到 2030 年关键软件全面实现智能化升级。我把这份文件当成一张任务书，拿客户内部一个售后工单分派流程做压力测试。

周六上午我在 WorkBuddy 里搭智能体，界面上是节点拖拽。我放了工单描述读取，接 MiniMax 做意图识别和优先级判断，再生成给一线工程师的回复草稿。第一次跑，意图能出来，但把“系统登录失败”和“账号被锁定”混为一类，优先级也乱。

我以为是小模型不行，换到测试环境跑，结果更明显，工单系统要求状态、负责人、SLA 同时更新，缺一个就报错。SaaS 这里指云端软件服务，不是本地 exe。下午卡住的是上下文。测试环境只能模拟数据，很多历史规则没同步。我这边测下来，最耗时间的是把“这次问题”和“上次问题”接起来，模型只看到当前工单，不知道历史处理记录。后来我建了一张上下文摘要表，把最近三次工单状态、负责人、处理结果带进去，才把节点跑绿。

界面里有个“运行历史”，点开能看到每个节点的输入输出。这个功能救了我。之前模型误判优先级，我只能靠猜。后来发现是旧工单摘要没被带进上下文，模型只看到当前这一句，不知道“还是上次那个问题”指的是哪一次。清理以后，判断才稳。

异常检查让我有点意外。我把两笔描述相近、客户相同的测试工单丢进去，智能体挑出“疑似同一问题重复开单”，并引用了原始工单号。这个不算多高级，但对一线初审有用。它能拦住明显不该进入下一步的东西，替代不了人。

周日我按 SB 53 检查表补日志。SB 53 是加州 AI 安全法案，我这几天刚上手拆成检查表，拿来当外部模板。补完以后，每一步能记录模型版本、提示词、调用了哪个系统、人工有没有确认。看着像成熟度问卷，但真出事时能救自己。

我还试了把智能编程辅助接进去，让开发同事生成一段调用校验代码。它确实能生成，但客户代码规范、异常处理、日志格式都不符合，改起来比手写还慢。这说明智能编程适合做脚手架，不适合直接交付。

新华社消息提到，到 2028 年推广应用覆盖 2 万家规模以上软件企业，累计组织实施 100 项软件企业智能化技改项目。

这句话离普通用户有点远。落到客户现场，就是工单少转两次、回复少写一段、升级少查一页。方案里说要坚持“应用牵引、创新驱动、安全可控、生态协同”，我这边更关心“安全可控、生态协同”能不能变成日志和回滚。

好处很直接，结构化数据规整时，生成工单摘要和会议记录确实省时间；流程可视化，业务和 IT 能对着同一张图吵架；异常检测能拦住低水平错误。坏处也很硬，脏数据下清洗功夫一分都省不掉；访问边界、错误处理、回滚机制要人配；模型输出仍然要复核，不能直接当处理结论。

这次试点给我的提醒是，别只看风口。智能体软件要落地，关键是把边界、日志和回滚配齐。能把这些配齐，才谈得上工程件。