AI 成本、Agent 方向与落地方向整理

这是一份面向内部沟通的简要整理，核心目标只有四个：

• 先把 token 成本讲清楚
• 再把 agent 的能力演进讲清楚
• 对 toC、toB、toG 的方向做一轮收敛
• 最后明确一个结论: 现阶段更适合先提效，再谈创新

一、先看 token 成本

现在做 AI，token 成本不是背景信息，而是前置条件。
如果成本模型不清楚，很多判断都会偏。

已知使用规模:

• 我个人一个月大约消耗 3 亿 token
• 少卿一个月大约消耗 6 亿 token

这里只展示独立数据，不做合并汇总。

成本对比表

方式	模型/方案	单价（元 / 百万 token）	备注
自部署	2 x 5090 + Ollama + Qwen 100B	约 25	成本主要来自显卡与电力，速度约 20 token/秒
国内官方接口	以 GLM 为例	约 10	见下方配图
国外模型官方接口	以 GPT-5.4 为例	约 50	这里按公开价格做简化理解
中转方案	以 GPT-5.4 为例	约 0.22	按现有渠道口径估算，延迟通常在 3 秒以上

计算细节

为了便于方便计算，价格 = （输入 + 输出）/ 2

1. 自部署模型

已知条件:

• 2 张 5090 显卡
• Ollama + Qwen 100B
• 速度约 20 token/秒
• 1 小时约 7 万 token
• 1 小时约耗电 1 度
• 电价按 1.8 元/度估算

1.8 元 / 0.07M = 25.7 元 / 百万 token

这个结果说明了一点:
我们自建模型，即便不算硬件成本，单看 token 的电费成本都很亏。
当然，如果是甲方自己部署，那就是另一回事。

2. 国内官方接口

这里以 GLM 价格为参考:

• 约 10 元 / 百万 token

配图如下:

3. 国外模型官方接口

这里用 GPT-5.4 作为高能力模型参考:

• 约 50 元 / 百万 token

4. 中转方案

按现有渠道测算:

• GPT-5.4 标称价格约 80 / 354
• 折算后约为 0.22 元 / 百万 token

配图如下:

这个价格的意义非常直接:
我们只计算图片中 GPT-5.4 的价格，图片中的美元符号是假的，实际是人民币。
如果稳定性和合规边界可控，中转方案在现阶段有极强的成本优势。

这里可以得出的判断

我们现在已经有了比其他正规渠道便宜几十倍的 token 来支撑我们。
不管是引入 AI 做内部提效，还是去做一些基于 AI 的产品，这都是一个很明显的优势。

二、Agent 的发展方向

现在 agent 发展特别快，几个月就会出来一个新概念。
这几年 Anthropic 这些公司的推进过程，大致可以概括成:

提示词工程师 -> 上下文工程师 -> harness 工程师 -> loop 工程师

现在是 2026 年，Anthropic 也才刚开始对外强调进入 loop 工程师这个阶段。

少卿有一句话我觉得很值得记一下:
“现在做 agent 尝试的公司，未来都会被模型自己干掉。”

他的意思我理解是，大模型公司比如 Anthropic、OpenAI 这些，未来模型能力会越来越强，强到把很多现在靠 agent 包起来的能力直接吃掉。

这个判断我认同一半。
未来模型本身当然会越来越强，但至少在现在这个阶段，agent 还是很有必要。

原因也很简单。
我们不能直接拿 OpenAI 的 API 就去稳定地写代码、改文件、跑命令、做验证。
中间还是需要 Claude Code、Codex 这种 agent 产品，把模型能力真正组织成一个可执行的工作流。

所以至少在现阶段，模型和 agent 不是替代关系，而是配合关系。
模型负责能力上限，agent 负责把能力真正落到执行链路里。

1. 提示词工程师

最早大家关注的是怎么把一句话说得更对。
这个阶段有价值，但只解决“怎么提问”。

2. 上下文工程师

接着大家发现，影响结果的不只是提示词，更关键的是给了模型什么上下文。
包括:

• 哪些文档要放进去
• 哪些历史要保留
• 哪些信息其实是噪音

3. Harness 工程师

再往后，重点不只是模型本身，而是模型外面的运行框架。
例如:

• 怎么调用工具
• 怎么读写文件
• 怎么做权限约束
• 怎么留痕和回放
• 怎么失败重试

很多 agent 效果差，不是模型不行，而是外层 harness 太弱。

4. Loop 工程师

现在更关键的是循环本身。
也就是让 agent 能否稳定地:

• 看当前状态
• 做下一步判断
• 执行动作
• 检查结果
• 决定是否继续

这比“写一个好提示词”更接近真实生产力。

对公司的直接意义

如果继续只把 AI 当成问答工具，用法会很浅。
如果开始按 loop 来设计，AI 才可能真正进入研发、运维、交付和支持环节。

三、业务落地方向

我不建议把方向讲得太散。
更适合收敛成三类: 贴近自有业务的场景、面向企业的交付场景、以及受环境限制明显的政企现场场景。

1. 结合现有业务做垂直能力

锁定某个行业或者领域后，才能具体推敲出 AI 能做什么。

例如:

• 有些单位需要长期宣贯领导讲话，那么是不是可以用 AI 自动做总结、提炼重点、生成学习材料
• 我们做交通相关项目时，是不是可以给现场情绪很紧张的事故人员提供 AI 辅助，告诉他下一步该联系谁、先做什么、材料怎么留

2. toC 方向

我平时也看一些视频、文章，感觉在 toC 领域做一些纯软的工具，即便做得好，也很难卖钱，推广是个大问题。

我的一个想法: 面向 agent 的通信工具

现有 IM 基本都是给人设计的，不是给 agent 协作设计的。
如果以后一个任务会同时调用多个 agent，那么 agent 与 agent 之间就需要一种可管理、可追踪、可授权的通信机制。

例如:

• 我的开发 agent 需要向另一个人的 agent 询问接口信息
• 两边 agent 可以在限定权限内自行闭环
• 全过程可以审计

这个方向未必马上成型，但它有明确问题意识，不是空泛概念。

3. toB 方向

toB 这边我感觉主要还是工作流、企业 AI 门户、知识库、RAG 这些方向，类似 Dify 这种。

比如这个: 53AI
他们的企业 AI 知识库这些我感觉就做得不错。

4. toG 与受限环境场景

toG 或强内网环境的机会，不在“模型更炫”，而在“现场约束很强，但问题又必须解决”。

这类场景往往有几个典型限制:

• 厂家无法直接远程
• 机器不能公网访问
• 现场支持人员能力参差不齐
• 问题定位和操作成本很高

这时，一个可控的 agent 反而有现实价值。

方向一: 面向普通人员的自然语言运维入口

例如把 shell 操作能力包装成自然语言工具，让不熟悉命令行的人也能完成基础操作。

示意如下:

这类产品的价值不在于替代专业运维，而在于降低基础操作门槛。

方向二: 面向局域网现场的“代理型 agent”

很多现场支持问题，本质上不是技术本身太难，而是执行链条太长。
研发知道怎么做，但到现场以后，经常要靠人肉转述和低效操作完成。

这个方向主要还是政府场景。
如果对方愿意让我们给这个 agent 开外网访问，那当然最好。
如果不行，也可以考虑通过短信，甚至电话去和 agent 沟通。

典型问题包括:

• 程序被放错目录，重启后文件消失
• 只改两个字段的配置，也可能折腾数小时
• 网络、路由、防火墙类问题很难高效排查

示意如下:

如果在局域网环境内部署一个受控 agent，模式就会变成:

• 厂家与 agent 协同
• agent 在授权范围内操作现场机器
• 所有动作留痕
• 操作边界可以提前定义

例如可以约束:

• 只允许操作指定 IP 段
• 只允许执行指定类型命令
• 所有操作必须保留审计日志

这类方案的价值，主要来自把“提线木偶式支持”替换成“受控自动执行”。

从效率上看，一个粗略对比是:

• 研发直接远程: 约 1 小时
• 依赖现场技术支持反复沟通: 约 1 天，甚至更久
• 与受控 agent 协作: 约 0.5 小时

这里的重点不是追求绝对数字，而是说明中间执行链条一旦缩短，交付效率会明显改善。

四、MCP 也是一个重要方向

如果一个产品未来希望被 AI 使用，那么它就不该只服务人，也应该能服务 agent。

MCP 的价值就在这里:
它让产品能力以标准化方式暴露给 agent 调用。

适合做 MCP 的能力很多，例如:

• 邮箱
• SSH
• 短信
• 记事本
• 浏览器
• 设计工具
• 内部业务系统

这个方向不一定直接变成一个独立产品，但它会显著提高产品被接入、被调用、被编排的可能性。

五、现阶段更适合先提效，再谈创新

我个人更倾向于这个顺序:

先提效，再创新

原因并不复杂。

先做提效的好处是，效果更直接，也更容易验证。
公司现在铺开的面很大，历史原因导致现在不是几个人开发一个模块，而是 1 个人开发几个模块，甚至还要兼顾产品，人力明显忙不过来。
还有一点不是 AI 能力做不出来，而是我现在其实可以做很多工具，比如自动运维工具，但没有项目经理给我把场景拉通，也没有人明确说做出来肯定会用，目前就李磊一个人表达过。

换句话说，现阶段先解决“今天的人怎么更快把事做完”，比先追求“做一个新的大产品”更稳。

为什么提效更适合作为第一优先级

• 成本更容易计算
• 效果更容易验证
• 落地链条更短
• 失败成本更低

例如:

• 控制团队 token 成本
• 把高频现场问题固化成可复用流程
• 沉淀标准化的代码协作方式
• 把一些个人经验变成别人也能调用的工具

这些事情做成以后，创新不是被放弃，而是有了更稳的基础。

六、公司内部可以优先推进的几件事

如果要往前走，比较适合优先推进的是这几类工作:

1. 控制并放大 AI 使用规模

目标不是少数人用得很深，而是让更多人以可控成本稳定使用。

2. 把个人高效率打法产品化

例如某些现场问题可以在几分钟内定位并解决，那么重点就应该是:

• 哪些步骤可以复用
• 哪些判断可以模板化
• 哪些工具可以沉淀成统一入口

3. 沉淀更标准化的研发协作方式

写代码这件事，目前大家还是偏个人习惯。
后面如果 agent 深度介入研发，最好逐步形成更标准的:

• 上下文组织方式
• 提示与任务描述方式
• 验证与交付方式

4. 给愿意使用 AI 的同事提供现成工具

不是所有人都会主动摸索。
如果有人已经愿意学、愿意用，那么更好的做法是尽快给他们足够顺手的工具，而不是让每个人都从零试错。

七、最后的判断

我的核心判断是:

• token 成本决定 AI 推进速度
• agent 的重点正在从提示词转向 loop
• 真正适合现在做的，不是过于发散的泛产品，而是贴近业务的可落地方向
• 现阶段公司更应该优先做提效，把内部效率、交付效率和支持效率先拉起来

如果这条线跑通了，后面的创新空间会更大，也更扎实。