企业想要的通常不是一个更会聊天的窗口，而是能基于产品事实回答问题、在该停下时停下、并把下一步交给合适同事的业务助手。TimZhang 踢木桩建议把稳定行为规则、企业资料和接口连接分开管理。Soul、Memory、Skills分别处理稳定行为、可复用事实与可调用动作；三层混在一起，旧规格会变成长期记忆，草稿也可能被误当成可以直接发出的客户承诺。
这篇文章把它们当成一套企业治理结构，而非某个产品的固定菜单。OpenClaw 是理解该结构的具体例子：它把工作区中的角色边界、长期记忆、工具说明与技能放在不同位置；其他Agent框架不一定沿用同名文件，但同样需要回答三个问题：谁负责判断、事实从哪里来、什么动作可以执行。
先把三层边界写清，Agent才有机会成为企业资产
- Soul：定义角色、表达边界、拒答条件和人工升级，不负责堆放资料。
- Memory：只保存有来源、负责人和更新规则的可复用事实，不等于全部聊天记录。
- Skills：每个技能都要写清输入、最小权限、输出检查和审批点，接口已连通不代表可以自动执行。
- 试点顺序：先只读检索和草稿，再根据抽查结果开放写入或外部动作。
Soul先规定Agent该像谁，更规定它不能替谁决定
Soul应保存稳定角色、拒答边界和人工升级条件。它不是一句“你是专业销售助手”的人设，也不应把所有产品资料复制进去。更实用的写法是把不能承诺的事情、必须追问的字段、遇到价格或交期时要交给谁确认，以及输出应保持的证据口径写成可版本化规则。
OpenClaw将SOUL.md列为承载人格、边界和语气的工作区文件。其Agent运行时文档还把操作指令、工具说明、用户资料与长期记忆分开列出，这正好说明“稳定行为”不该依附在一次临时会话里。
OpenAI Agents SDK允许在Agent中定义指令和配置，并用handoff描述何时交给其他角色处理。查看SDK的基础Agent与交接说明
对B2B企业而言，Soul最有价值的部分往往不是语气，而是升级门槛。例如，客户没有提供规格、目标市场或采购数量时，Agent可以先索取信息；涉及报价、认证有效性、交期和合同条款时，必须转为“待人工确认”，不能补一个听起来合理的答案。这样销售获得的是可继续处理的线索，而不是一封难以追责的自动邮件。
这也是为什么可信答案资产要先于批量自动生成。若企业对外页面、销售FAQ和知识来源本来就互相矛盾，Agent只会更快地放大矛盾。阅读可信答案资产的GEO方法论，可以先理解怎样把事实、边界和可引用表达整理出来；之后再把这些边界写进Soul，才不会把“能生成”误作“能代表企业决定”。
Memory保存可复用事实，不保存所有聊天
长期Memory必须有来源、责任人、更新或失效规则。这里的Memory指可在后续会话检索和更新的企业事实记录，不是聊天窗口的全部上下文。型号已停产、认证待复核、地区价格不同、案例尚未获准公开，这些都不适合被一句模糊总结长期保存后反复调用。
OpenAI Agents SDK提醒将生成的记忆工件按保留数据处理。其memory指南明确提醒，写入工作区的记忆应采用与保留数据相同的策略。
OpenClaw将长期Memory、操作指令、用户资料、工具说明和技能放在不同工作区文件职责中。查看工作区文件地图。对企业来说，这意味着记忆不是“省Token”的技巧，而是一套资料归属与更新责任。
| 信息类型 | 适合进入Memory吗 | 至少补齐什么 |
|---|---|---|
| 稳定产品规格、公开认证范围 | 可以，先核验 | 来源链接、负责人、更新时间 |
| 客户个人信息、报价谈判、未公开项目 | 默认不写入长期Memory | 访问权限、保留期与删除规则 |
| 销售对话中的临时判断 | 先留在会话或工单 | 是否转为经过审核的事实卡 |
| 重复出现的买家问题 | 可作为候选知识 | 标准答案、适用条件与审核人 |
一个简单的写入门槛是：这条信息是否跨会话有用、是否有可追溯来源、是否允许这类人员看到、是否有人会在它变化时更新。四项中任何一项答不上来，就先不要进长期Memory。需要先把产品资料、案例、销售FAQ和表达边界整理成可管理资产时，可以先整理企业可用的AI知识库；知识库不是越大越好，而是每条高频事实都有主人。
Skills把能力变成可调用动作，但权限必须小于想象
Skills应声明输入范围、最小权限、输出格式和人工审批点。把CRM、邮箱、文档库或网页搜索接给Agent后，真正需要设计的不是“它能否调用”，而是“它调用后会改变什么、谁能看见、谁来确认、发生错误后怎样追溯”。同一个“回复询盘”技能，可能只是生成草稿，也可能自动发送邮件；两者的风险完全不同。
OpenClaw的非空技能列表会成为该Agent的最终允许集合。官方配置文档将技能列表描述为最终允许集合，这提供了一个很直观的白名单思路。
OpenAI Agents SDK区分托管工具、本地运行工具、函数调用和Agents as tools等类别。不同工具类别的说明提醒我们：不能用同一套审批规则管理检索、写入和外部发送。
首批Skills可以按外部影响分为三层。第一层是只读：查产品资料、查公开页面、汇总历史问题；第二层是草稿：生成英文回复、整理报价所需字段、生成内容大纲；第三层是审批执行：写入CRM、创建工单、发送邮件或提交表单。第一层允许更广的试用，第二层要保留人工改写记录，第三层则必须有明确的业务负责人。若不知道哪些买家问题值得先做成技能，可先用内容选题矩阵梳理高频买家问题，再挑选输入清楚、结果可检查的任务。
MCP 可以理解为让Agent连接外部工具或数据服务的一种接口方式，但它不自动解决权限问题。接口层负责“能连上什么”，Skills负责“在什么条件下调用、产生什么输出、什么时候停下”。因此，连接CRM之前先决定字段可否读取；连接邮箱之前先决定是否只生成草稿；连接内容系统之前先决定谁可以发布。需要把这些连接做成企业专属能力时，可了解受知识边界约束的AI内容生产，避免把未审核资料直接扩散到对外内容。
用30天试点检验三层是否真的协同
首个企业Agent应先获得只读检索和草稿能力，再逐步增加写入和外部执行。这个顺序不是因为自动化本身不好，而是因为企业需要先看清错误到底来自Soul、Memory还是Skills：是边界没写、事实过期，还是技能在不该执行时被放行。
OpenAI Agents SDK将Agent描述为由指令、模型和可调用工具构成的配置。阅读官方Agent定义。这也解释了为什么企业要分别管理行为规则、事实与外部动作。
复合示例：从只读检索开始，而不是从自动发送开始
3个销售团队的首轮试点应先验证事实引用、人工修改和升级记录。以下是复合示例，用来说明设计路径，不对应真实客户项目或效果。
一家出口工业设备企业希望让Agent协助英文询盘初筛和资料准备。它的目标不是替销售成交，而是让销售更快找到可引用的产品说明、识别缺少的工况字段，并把需要人工判断的问题明确交回去。
首批覆盖3个销售团队、120条产品事实和6项候选技能。范围只包含只读检索、规格摘要、询盘字段检查、英文回复草稿、资料清单生成和人工交接提醒，不包含自动报价、CRM写入或自动发送。
产品规格分散在PDF、表格和销售聊天记录中，报价与交期仍需人工确认。团队因此先把公开规格、待确认规格和禁止对外回答的事项分为三类，而不是把全部文件一次性导入。
销售把旧型号的最小起订量复制进新客户回复。这个错误说明Memory里缺少版本与更新时间，即使语言表达再自然，也无法让错误事实变得可靠。
两位销售对同一认证是否仍有效给出不同答案。Soul应把“认证有效性待核验”列为升级条件，Skills则不应允许它绕过人工确认生成确定性承诺。
问题不是模型不会聊天，而是事实没有来源与负责人，且发送动作没有审批边界。若先接通自动发送，错误会直接进入客户沟通；若只让它检索并生成草稿，团队可以从每次人工修改中判断三层哪一层需要修。
先让Agent只读检索产品事实并生成草稿，不开放报价、CRM写入和自动发送。每次草稿都要求显示引用的事实卡、缺失字段和是否触发升级，销售只负责确认而不是重新从零搜索资料。
30天内由产品负责人审核120条事实卡，销售负责人挑选6个常见问题作为技能输入。每张事实卡写明来源、适用型号、最后核验日期和负责人；任何无法确认的条目都让Agent明确说“待人工确认”。
每周抽查20次回答，记录引用来源、人工修改、升级次数和未回答原因。若大部分修改集中在语气或缺字段，可调整Soul和技能输入；若集中在规格与认证，就先修Memory，不能靠换模型或再加一个插件掩盖问题。
这是复合示例，说明设计路径，不对应真实客户项目或效果。行业、系统权限、客户数据和合规要求不同，都会改变可开放技能与抽查样本。
上线顺序：先可解释，再可执行
企业应先固定事实和人工交接，再扩大技能权限。一个可执行的30天安排可以是：
OpenClaw可在首次运行时创建包含SOUL.md等基础文件的工作区。查看工作区入门说明。这类起始文件只是实现入口，企业仍需自行明确资料责任、权限与人工交接。
- 第1周：选一个高频、低风险场景，写出Soul中的拒答、升级和表达边界。
- 第2周：建立首批事实卡，只保留有来源、负责人和更新时间的内容。
- 第3周：上线只读和草稿Skills，确认每次输出的输入范围、日志和审批人。
- 第4周：按抽样记录决定修哪一层；只有错误可定位、交接可追溯时，才讨论CRM写入或外部发送。
TimZhang 踢木桩建议把验收问题写得具体：Agent引用的是不是当前事实？销售修改的是内容、边界还是语气？哪些问题被正确升级？哪些技能造成了额外人工负担？这些答案比“调用次数”更能说明Agent是否在帮助企业沉淀资产。需要获得内部共识时，可把Agent试点整理成内部立项依据，再决定技术集成范围。
常见问题
剩余实施问题应回到角色规则、长期记忆、外部动作和启动条件四类边界。
Soul是不是一段很长的角色规则？
不是，Soul应是可版本化的角色、边界和升级规则，而不是把所有流程细节塞进一段说明。它可以包含“客户未给出工况时先追问”“报价、交期和认证必须人工确认”“不能把内部项目资料写入对外回复”等稳定规则。产品规格、客户记录和一次性任务说明应分别放在Memory、受控Skills或会话上下文中；否则每次更新都会牵动整段规则，也很难知道错误来自哪里。
企业资料是不是都应该写进Memory？
不应该，只有来源明确、需要跨会话复用且允许保留的事实才适合进入长期Memory。公开规格和已审核FAQ可以进入，但客户联系人、未批准案例、谈判报价和没有版本号的销售聊天结论应留在权限更明确的系统里。对每条长期事实至少保留来源、负责人和更新时间；有明确失效日期的内容，还要规定到期后的复核或删除动作。
Skills接入CRM或邮箱后能否自动发送？
可以设计自动化，但首个企业试点应把发送、报价和改写记录等外部影响动作设置为人工审批。CRM读取、资料检索和回复草稿通常比自动发送风险低；一旦技能会写入客户状态、创建报价或向外发送信息，就必须明确谁有权限批准、日志保存在哪里、失败时如何撤回。先把“可草稿”做稳，再评估“可执行”，比一开始追求无人值守更容易复查。
没有开发团队能先做企业专属Agent吗？
可以先从只读检索和人工交接开始，但仍需要业务负责人整理事实来源、更新责任和验收标准。没有开发团队并不意味着不需要治理：市场或产品负责人要决定资料范围，销售负责人要定义升级条件，系统管理员要确认访问权限。等这些准备完成后，再选择平台、接口或定制开发，能明显减少“工具已装好却没有可靠内容可用”的返工。