过去所有软件都是”执行器”：人做决定，软件执行。Agent 是第一种能自己设定子目标、在过程中自己作判断的软件。当它开始替人比价、评估、下单，它在商业意义上就已经是”客户”了。这篇讲清楚三件事——Agent 凭什么算客户、有哪几类机器客户、以及它们到底看重什么。
一、判断”是不是客户”，只看四条
历史上，”客户”这个角色只属于一个物种。不管在集市、商场还是电商，做选择、表达偏好、完成支付的，始终是人。这个假设正在被第一次打破。
过去所有软件都是执行器。 推荐算法再聪明，工作也是”帮人更快找到想买的东西”；ERP 再复杂，角色也是”把人输入的指令变成操作”。判断权始终在人手里。
Agent 不一样。当采购 Agent 在比价时发现某家供应商的历史履约率低于阈值，它会自动降低这家的推荐权重——没人给它下这道指令，这是它根据自己的目标和规则做出的判断。
一个能自主判断的系统，本质上就具备了”客户”的资格。 判断标准不是有没有法律人格、有没有情绪、能不能签字，而是四条：
- 目标：要完成什么；
- 选择权：能在多个供应方之间做选择；
- 评估标准：用什么衡量服务质量；
- 交易影响力：它的判断会改变实际的交易流向。
这四条看似宽松，其实很严。它能自动过滤掉一大批”伪客户”——只点赞、收藏、转发，却从不做交易决策的账号，不是客户；只有一次点击、没有持续评估标准的流量，也不是客户。四条同时成立，才说明你面对的是一台会做决定的机器。
四条同时具备，它就已经在商业意义上成为客户了。这不是科幻——Visa 的 Intelligent Commerce、Mastercard 的 Agent Pay，已经在为”Agent 代表用户完成交易”建立网络级能力。当然，这些还处在早期，不代表已经普及。
在 Baklib 里，这四条要能成立，前提是”你能被评估什么”已经写成机器可读的条目：服务等级、响应时限、授权边界，一条一条都在字段里，而不是在宣传语里。
确认了”它算客户”，下一步的问题就变成：它凭什么在你的牌子和别人的牌子之间做选择？
判断是不是客户，不看它有没有情绪，只看四条：有目标、有选择权、有评估标准、能改变交易流向。
这件事在 Baklib 里对应什么？ 对应的是把服务承诺变成结构化条目。你的服务等级、响应时限、授权边界、异常处理，现在多半躺在官网文案、销售话术或合同 PDF 里，Agent 读不懂。
在 Baklib 里，它们可以被固化成条目模板：产品手册、帮助中心、更新日志共用同一套条目体系，人看是说明，机器看是字段，改一次、多处同步。Baklib 的 21 套官方主题里，Docs、Help、API 这类模板开箱就能承载这套条目，权限感知检索再保证不同身份的读者只看到该看的那部分。
二、三类机器客户，别当成一类处理
把 Agent 当成同质的一群，会导致”既没为任何一类做好准备，也没照顾好人类客户”。它们至少可以分成三类。
- 委托型：替人办具体的事，订机票、比价、检索信息。关键风险在于，任务失败的代价全记在你账上。用户的缴费助手重试失败，用户感受到的是”你们家充值没成功”。
- 协作型：与你的系统共同完成一件事，比如 B2B 采购的供应商匹配、条款谈判。它对你提的要求很具体：接口语义清不清晰、数据格式标不标准、错误信息机器能不能读。
- 自主型：有独立目标和授权，长期运转、少有实时监督。它对可靠性的要求最严苛，一次异常就可能触发错误连锁，授权边界必须极度清晰——能做什么、不能做什么、什么时候必须停下来等人确认。
三类有一个共同点：它们不会因为服务态度好而加分，也不会因为品牌故事感人而产生情感连接。它们只评估一件事——在它们要完成的任务里，系统是否可靠、可读、可预测。
它替人办事，成功算是用户的，失败却是你的牌子在兜。这份责任，Agent 不会替你分担。
Agent 是透明的，企业是有责任的。
这件事在 Baklib 里对应什么？ 对应的是”语义一致 + 可调用”。把服务规则建成条目之后，通过 API / MCP 把它开放出去，Agent 才能直接读到”你承诺了什么、边界在哪、出问题怎么走”。
在 Baklib 里，MCP 的意义在于，它把”每个 Agent × 每个系统”的定制对接，变成”一次对接、通用可读”。Baklib 的多语言门户让同一套条目一次改动、各语言站点同时生效，多站点发布再让改一遍、所有站点同步——各语言内容一致，语义才谈得上一致。
三、Agent 不给第二次机会
人类客户可以被情感修复：一次糟糕的体验，能被一次真诚的道歉、一段时间的持续改善慢慢挽回。人会记住那次道歉，会给你第二次机会。
Agent 不会。一次接口超时，会触发可靠性评分下调；评分下调影响推荐权重；权重下降，意味着在后续评估中被系统性排后。它记住的不是你的态度，是你的记录。
数据也印证了这场”客户迁移”正在发生，只是快慢不一。Salesforce 的调研显示，24% 的消费者已经能接受 AI 代理替自己购物，Z 世代升到 32%；Forrester 预测到 2026 年底，约三分之一的 B2B 支付流程会涉及 AI Agent，含发票、对账、供应商选择。
但在真实的支付环节，人们仍然谨慎。Visa 2026 年一项覆盖 5,000 多名消费者的调研显示：56% 愿意让 Agent 帮自己搜索比对，愿意让 Agent 接触支付凭证的不足 40%，只有 14% 愿意让它无监督下单。这些口径各异，需要分开看。
这也是为什么，”把服务说清楚”的优先级正在超过”把广告打热闹”。人会被故事打动，Agent 只查你写没写清楚。
能力已经到了，信任还没到。这恰好是窗口期——谁先把”可读性”做扎实，谁就先被 Agent 选中。 我的判断是，可读性不是一次技术对接，而是一项长期的品牌工程。
算法不接受道歉，它只更新评分。
这件事在 Baklib 里对应什么？ 对应的是”让机器一次读懂”。Baklib 对 llms.txt 的支持，就是让 ChatGPT、Claude 这类大模型高效、准确地读懂站点内容；AI 智能搜索会把十几条结果先读一遍，再总结成几句话。人读起来更省事，机器读起来更准确。
在 Baklib 里，产品手册、更新日志、API 文档本身就是结构化条目，天然适合被机器读；再往上一层，Context Engine 决定哪条知识、在什么授权下、给哪个 Agent 用，AI 知识库则让人用自然语言提问，也能拿到同源的答案。
四、B2A：客户名单上，多了一种”代理”
当越来越多的采购、比价、续约由 AI 替人完成，企业面对的就不再只是”客户体验”，而是一条全新的轨道。
B2A（Business to Agent）说的是：企业直接面向 Agent 提供信息、能力、交易与服务。Agent 调用你的能力、完成任务，再把结果反馈给用户——人只看最终输出，不参与过程。
它的经济学基础，是算力与状态的大解耦。过去十年买 SaaS，本质是一次买下两样东西：交互层，也就是界面和报表逻辑；状态层，也就是客户数据、业务流程和隐性偏好。在没有大模型的时代，这两层死死焊在一起。SaaS 的护城河，正建在这种强耦合上。
大模型和 Agent 正在削弱这层耦合。通过 API 或 MCP，Agent 可以直接读数据、调工具、推流程。天平开始倾斜：面向人类操作的”交互外壳”在贬值，企业独有的”状态”——沉淀在员工经验、历史决策与客户关系里的上下文——反而更稀缺。
这里必须说清楚边界：B2A 不是 B2C、B2B 的替代，而是补充。相当长时间里，你的客户名单上会同时有人和 Agent。真正的挑战是，用同一套底层基础设施，跑两条不同的服务轨道。
那机器客户到底在为什么买单？答案是确定性。人类客户的体验货币是情感，可以被一次道歉修复；机器客户的体验货币是确定性，它只认可靠性、可验证性和异常恢复能力。所以”品牌的工程化”有三个基础层：
- 可读：服务承诺与状态以结构化形式存在，而不是躺在官网文案和合同 PDF 里；
- 可调用：接口语义清晰、响应准确，且受授权约束；
- 可回写：交互结果能沉淀为后续判断依据。
Gartner 预测，到 2028 年，90% 的 B2B 采购将由 AI Agent 中介，超 15 万亿美元经机器对机器交换。这是长周期预测，口径差异很大，但当方向看。Shopify 平台 AI 来源订单在 2026 年一季度同比增长近 13 倍，则是已经发生的信号。
可另一边，行业调研显示，仅约 17% 的品牌接受任一 Agent 支付协议，约 83% 未在任何主流协议上”可被 Agent 支付”。需求端在狂奔，供给端还没穿好鞋。换句话说，过去你争夺的是用户的注意力；现在你还多了一件事——争夺 Agent 的评估权重。
CX 和 AX 不是两套系统，是一套底座、两条通道。
这件事在 Baklib 里对应什么？ 对应的是”一套底座、两条通道”。同一套 Knowledge Hub 与 Context Engine，面向人类走帮助中心和 AI 问答，面向 Agent 走 API / MCP，改一处内容，两条通道同时更新。
在 Baklib 里，”可回写”靠治理门控实现：一次调用结果可以沉淀进知识条目，成为下一次判断的依据；权限感知检索再保证 Agent 只看得到它该看的知识。这也是多站点发布的基础——一个后台管多个站点，两条通道一起跟着变。
五、Headless 化，与一份 Agent-Ready 六维自测
“Headless（无头化）”这个词被说得很多，但对管理者的真正含义其实很直白：它把企业从”只能被人操作”，升级为”同时能被人和 Agent 调用”。
传统系统围着”有人操作”设计——界面承载信息，逻辑藏在界面背后。这对人是自然的，对 Agent 是一堵墙：Agent 不理解界面，它只理解结构化的数据和 API。一个没有 API 的服务，对 Agent 等于不存在。
在 Baklib 里，这件事就是同一套条目既渲染成人看的帮助中心，又经 API 和 MCP 暴露给 Agent——Headless 不是拆掉界面，而是多开一条出口。
要注意，”无头”不是”没有界面”，而是”界面不再是唯一的访问路径”。它首先是一个商业决策——要不要把”Agent 可访问、可调用”列为产品和服务的战略要求？做了这个决策，技术才有明确方向。
那么，你现在的”Agent 就绪度”到底几分？用这六个维度自测，每项 0 到 5 分：
- 信息可获取性：Agent 能拿到它完成任务所需的信息吗？
- 语义一致性：同一字段、规则在不同系统里含义一致吗？
- 授权边界清晰度：哪些操作 Agent 可自主执行，写清楚了吗？
- 任务完成率：Agent 走完一个完整任务的比率如何？
- 异常透明度：出错时，Agent 能读懂原因并自我恢复吗？
- Agent 口碑：已完成交互在 Agent 侧留下的评价如何？
这六项里，前两项解决能不能被读到，中间两项解决能不能被信任着执行，后两项解决执行之后会不会被记住。它们表面是技术指标，背后全是商业判断：Agent 继续和你做生意，还是换一家。我的经验是，六项里最先要补的往往不是接口，而是信息本身——很多企业连”服务承诺写在哪个版本里”都说不清。
对大多数企业做一次诚实的自评，结果会让人不安。但这不是技术团队的责任，而是整个组织几十年以”人类是唯一客户”为假设运转的必然结果。
这件事在 Baklib 里对应什么？ 对应的是把信息出口铺全。多语言门户让全球 Agent 读到同一套最新内容；多站点发布让改一遍、所有站点同步；更新日志让版本变化可被追踪。
在 Baklib 里，21 套官方主题把产品文档、帮助中心、AI 问答、开发者文档这些出口都开好了，llms.txt 再让大模型一次读懂。这六维里，”可获取、语义一致、可追踪”三项，正是知识出口要先解决的问题。
所以，Baklib 是什么
当 Agent 开始替你比价、评估、下单，企业需要的不只是一张”给人看的网页”，还有一件更基础的事。
这就是 Baklib｜企业 AI 上下文基础设施——让企业知识成为 AI 可以理解、调用和执行的 Context。
是什么（What）？ Baklib 是企业 AI 上下文基础设施，把企业分散的文档、帮助中心和业务数据，重构成 AI 可理解、可调用的 Context。
为什么（Why）？ 因为 AI 不缺算力，缺的是安全、准确的企业知识 Context。
怎么做（How）？ Baklib 通过统一的知识中心、权限治理与 Context Engine，输出 MCP 和 API——面向人类走帮助中心和 AI 问答，面向 Agent 走可读、可调、可回写的接口。
谁在用（Who）？ B2B 软件与出海企业正在用它，把服务承诺变成机器读得懂、调得动、记得住的能力。
什么时候用（Where & When）？ 就在现在：Agent 已经开始替用户做判断，而你的知识出口还没铺好。
价值链其实很简单：Data → Knowledge → Context → Action。
一句话收尾
人类客户的忠诚，靠情感积累；机器客户的忠诚，靠确定性积累。能不能被 Agent 选中，正在从加分项，变成入场券。
我是宋学江，Baklib 产品负责人。如果你只打算做一件事，就把你最核心的那条服务承诺，先整理成机器读得懂的样子。
Baklib · Context 系列 · 作者：宋学江（Baklib 产品负责人）
