Agent 是复杂个性化需求的最优解:解决用户自己都说不清的问题

为什么传统软件解决不了的需求,Agent 能解决?因为它不需要你先想清楚

上周帮一个客户上线了一个"智能周报助手"。需求方的原话是:“帮我们的销售团队自动生成周报。”

听起来很简单。但往下聊五分钟,你会发现这句话背后藏着至少二十个未定义的决策:周报包含哪些维度?数据从哪来?不同区域的销售负责人关注点一样吗?“好的周报"到底长什么样?客户自己也说不清。

最终的解决方案不是一个固定模板的报表工具,而是一个 Agent——它能根据每个销售负责人的历史偏好、当周数据特征、团队上下文,动态决定周报的结构、重点和措辞。

这件事让我重新思考一个问题:Agent 的核心价值到底是什么? 不是"自动化”,不是"降本",而是——它是目前唯一能规模化解决"复杂个性化需求"的技术方案

[Read More]

当 10 万个定时任务同时敲门:MaaS 平台调度优化实战

从整点风暴到分布式调度——平台视角的六个关键策略

上周五下午 3 点,告警群炸了:MaaS 层的 GPU 推理集群 QPS 在 60 秒内从 1200 飙到 18000,p99 延迟从 800ms 打到 45 秒,大量请求 429。

排查发现原因很"朴素"——大约 3 万个 OpenClaw 实例的定时任务都跑在整点。每个实例可能只有 1-3 个 cron job(数据摘要、定时巡检、报表生成),但所有人的 cron 都写着 0 * * * *0 0 * * *。三万乘以三,就是整点瞬间涌来的近十万个 LLM 推理请求。

这不是应用层的 bug,而是平台设计的缺陷。当你的平台承载成千上万个租户的定时任务时,“整点风暴"不是意外——它是必然。问题是:作为平台设计者,你该怎么办?

[Read More]

AI 原生的思考方式:不能被 Token 解决的问题,才配叫问题

上周,一个做 ToB SaaS 的朋友跟我吐槽:他花了两周让 AI 帮忙写了一套完整的 CRM 后端,代码质量不错,测试覆盖率也够。但上线三天就被叫停了——因为产品方向本身就是错的,客户根本不需要这个功能。

两周的 Token 消耗,毁于一个没被认真思考过的问题。

[Read More]

别再手动整理用户反馈了:把 VOC 变成一条自动化生产线

从原始用户声音到产品 Backlog,一套可落地的端到端自动化流水线设计教程

每家公司都说"以用户为中心",但 90% 的用户声音(Voice of Customer, VOC)最终的归宿是——躺在某个 Excel 表里,等着某个产品经理"有空的时候"去翻一翻。

问题不是团队不重视用户反馈。问题是:从原始反馈到可执行的产品动作之间,隔着太多手工活。 收集、清洗、分类、归因、优先级排序、写进 Backlog——每一步都在消耗人的精力,而人的精力是有限的。

这篇文章是一个完整的教程:如何用 AI + 自动化工具,把 VOC 变成一条可执行的生产线——从原始数据采集,到最终输出结构化的产品需求,全程自动。

[Read More]

别用同一把尺子量所有 Agent:按行业和岗位设计评测体系才是正经事

通用任务型 Agent 评测的核心矛盾——以及一套可落地的分层评测框架设计

上个月参加一个 Agent 产品的内部评审,产品经理拿出一张 benchmark 表格:准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮,领导很满意。

然后我问了一个问题:“这个 92% 的准确率,是在什么任务上测的?”

回答是一组通用 QA 数据集。

我又问:“你的目标用户是电商运营,你有没有用电商运营真实工作场景的任务来测?”

会议室安静了五秒钟。

这就是今天 Agent 评测的核心矛盾:我们在用"通用考试"的成绩来预测"专业岗位"的表现。 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立,但大家都在这么干。

[Read More]

同一个生意做了四遍:从搜索到Agent,万物皆排序

搜索、广告、推荐、Agent——四代系统的底层逻辑和商业本质,从未改变

如果你在过去二十年里分别做过搜索引擎、广告系统、推荐系统,再到今天做AI Agent,你可能会有一个越来越强烈的感觉:这不就是同一个生意吗?

表面上看,Google做搜索、Meta做广告、抖音做推荐、OpenAI做Agent,四个完全不同的产品形态,四个不同的技术栈,甚至四个不同的行业叙事。但如果你把外壳剥掉,盯着底层看,会发现一个令人不安的事实:这四代系统的核心逻辑,从来没有变过。

它们都在做同一件事——在信息过载的世界里,帮用户匹配到最相关的东西,然后从匹配效率的提升中抽税。

[Read More]

Agent的架构之战:从Desktop到AI时代,架构决定平台的生死

架构不是技术选型,是产品能走多远、用户体验能做多好的根本约束

每一代平台级产品的竞争,最终都不是功能之争,而是架构之争。Windows赢了OS/2,不是因为功能更多,而是因为它的架构让第三方开发者能更容易地构建应用。iOS赢了Symbian,不是因为初期功能更强,而是因为它的架构从第一天就为触控交互和应用生态设计。Chrome赢了IE,不是因为它一开始更快,而是因为多进程架构让它在页面崩溃时不会拖垮整个浏览器。

现在,AI Agent正在成为从Desktop、Web、Mobile之后的第四代平台级产品。而历史正在重演:决定谁能赢的,不是谁的模型更强、谁的功能更多,而是谁的架构更对。

[Read More]

企业级 AI 必须设计成出错后可以追责到人

从'AI 做的'到'谁让 AI 这么做的'——构建可追责的 AI 系统

上周一个真实案例:某电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价策略,导致部分商品以成本价以下售出,一天亏了 80 万。复盘会上,所有人面面相觑——

运营说:“我没动过,是 AI 自动调的。” 技术说:“模型输出没问题,是数据源有异常。” 数据团队说:“数据是实时抓取的,跟我们无关。”

没有一个人为这 80 万负责。

这不是个例。当 AI 从"辅助工具"升级为"执行主体",一个被企业严重低估的问题出现了:出了事,找谁?

[Read More]

AI的MaaS层最核心的能力:把一个不稳定的概率接口,变成一个可运营的服务

Model as a Service不是套壳API,而是AI应用从Demo到生产的关键基础设施

很多人对MaaS(Model as a Service)的理解停留在"套一层API"——把OpenAI的接口包一下,加个Key管理,做个用量统计,就叫MaaS了。如果这就是MaaS的全部,那它确实没什么技术含量,随便一个API Gateway就能干。

但现实是:几乎所有在生产环境跑AI应用的团队,最终都会自建或依赖一个MaaS层。 不是因为他们闲,而是因为裸调模型API在生产环境里根本撑不住。

MaaS层真正要解决的问题是:把一个概率性的、无状态的、昂贵的模型API调用,变成一个可靠的、可观测的、成本可控的服务。

[Read More]

OpenClaw + Claude Code 协同:用 Sub-Agent 执行编程任务并实时同步进度

从 stream-json 到钉钉通知,打通 AI 编程任务的全链路可观测性

你在钉钉里对 AI 助手说:“帮我写一个博客文章”,然后 Agent 回复"好的"——接下来呢?你等了 3 分钟、5 分钟、10 分钟,不知道它在干什么、进展到哪了、是不是卡住了。这是所有 Agent 系统面临的共同问题:编程类耗时任务的进度黑洞

OpenClaw 通过 Sub-Agent 机制调用 Claude Code 执行编程任务,再借助 stream-json 输出格式和一个轻量级的监控脚本,将任务进度实时同步到钉钉。本文完整拆解这套方案的架构设计和实现细节。

[Read More]