企业官网建设流程全解析

1. 从一个诡异的故障说起：协作越"紧密"，系统越脆弱

先说一件我实际遇到过的事。

去年我在调一个多 Agent 的客服系统，结构很简单：一个售前 Agent 负责推荐商品和解答购买问题，一个售后 Agent 负责退换货、退款、物流异常。当时我犯了一个非常"直觉化"的错误——为了让两个 Agent"协作得更好"，我给它们配了一个完全共享的长期记忆库。我的想法很朴素：既然是一个团队，信息当然要互通有无，售前聊完的用户诉求，售后接手时就能直接看到历史，不用再重新问一遍。

上线头两周一切正常。然后某天下午，售前 Agent 开始在一个商品推荐回复里，一本正经地引用一条"该商品支持 90 天无理由退款"的政策。问题是，这条政策从头到尾都不存在。我查了知识库，没有任何一条文档写过这句话。可以追溯到源头，是售后 Agent 在处理一个用户投诉时，为了安抚情绪，自己"推断"出了这个政策并写进了共享记忆。售前 Agent 在第二天读到这段记忆后，果断把它当成了权威依据，继续在对话里扩散它。用户越问越细，售前 Agent 为了自圆其说，甚至编出了更详细的退款流程。一个根本不存在的政策，就这样在"协作"中被反复强化，最后变成了系统里最稳定的错误事实。

这次故障让我意识到一个核心问题：我们通常理解的"协作"——信息越透明、共享越彻底、每个成员越了解彼此——在多 Agent 系统里恰恰是灾难的起点。

真正工程意义上的多 Agent 协作，不是靠信息无限流动来达成的。它靠的是另一件事：把边界定义清楚。谁负责什么、谁能读什么、谁能写什么、谁在什么情况下把问题交给谁。边界不是协作的反义词，边界恰恰是协作能够稳定发生的前提条件。就像结构工程里，墙体不是用来隔绝空间的，它是用来定义荷载路径、控制裂缝传播方向的。

这篇文章我就想把关于"边界"的思考完整地梳理一遍：多 Agent 系统里到底有哪些边界，它们失效时是什么样的，我们如何在工程上把它们设计得足够坚固，以及在运行时如何监控和维护它们。适合正在用 LangGraph、CrewAI、AutoGen 或自研框架搭多 Agent 应用的人，也适合那些已经在生产环境里被"协作得很好"的 Agent 团队坑过、却说不清楚问题出在哪的人。

2. 多 Agent 系统里到底有哪些边界——四种边界及它们的职责

很多人想到"多 Agent 边界"，第一反应是"隔离 Agent 之间的信息"。这个理解没错，但太粗糙了。边界不是一道墙，而是许多道性质完全不同的墙。我习惯把多 Agent 系统中的边界分成四类：知识边界、状态边界、权限边界、职责边界。它们的失效方式不同，修复手段也不同，混在一起讨论就容易抓瞎。

先举个生活化的比喻。一个运转良好的项目组，不是所有人都知道所有事。销售知道合同报价，工程师知道技术瓶颈，法务知道风险条款。PM 不会要求销售去审核代码规范，工程师也不会去拍板客户赔付方案。每个人守着自己的边界，只在特定的"接口点"交换信息——比如每日站会、PRD 评审、变更通知。真正的团队协作发生在这些交接点上，不是发生在所有人的大脑里。

多 Agent 系统也是一样的道理。只不过 Agent 没有职业素养和社会常识，它不会自动判断"这条信息是不是我该看的""这个操作是不是我该做的"。如果你不给它边界，它什么都敢读、什么都敢写。下面我把四类边界分别拆开说清楚。

知识边界（Knowledge Boundary）：Agent 在回答问题时，允许引用哪些知识域。售前 Agent 只能查商品库、价格表、库存数据；售后 Agent 只能查订单状态、退换货规则、物流接口。知识边界的核心问题不是"模型知道什么"，而是"模型在运行时能检索和引用什么"。大模型的训练知识是公用的、打开的，但一次具体的推理，其知识来源完全可以并且应该被约束在某个范围内。

状态边界（State Boundary）：Agent 能读写哪些记忆。这里说的记忆包括短期记忆（当前会话中的几轮上下文）和长期记忆（跨会话的向量库、结构化存储、文件缓存）。状态边界失效是四类边界里最隐蔽的，因为记忆篡改不像知识污染那样直接反映在回答内容上，它会在几十轮对话之后才暴露出来——一个 Agent 基于另一条 Agent 留下的错误推断做出了关键决策。

权限边界（Permission Boundary）：Agent 允许调用哪些工具和外部接口。这个最接近传统后端系统的权限模型。查询订单接口、写数据库、发送邮件、操作文件系统，每一项都应该有明确的"谁可以碰"的清单。权限边界往往被多 Agent 开发者忽略的原因在于：开发期只有一个 Agent 在跑，或者所有 Agent 都共用同一个 API Key，权限问题根本不显形。一旦 Agent 数量上来、分工细化，权限边界就成了系统安全的第一道闸门。

职责边界（Responsibility Boundary）：在特定任务流中，到底由哪个 Agent 主导处理这件事。职责边界不是静态的"你负责售前、我负责售后"，而是动态的——当一个会话从售前流转到售后时，谁接管主导权，谁退居只读辅助。职责边界失效的典型表现是"抢答"：多个 Agent 同时对同一个用户诉求给出回复，而且回复口径不一致，系统整体表现就像人格分裂。

为了看起来更直观，我把这四类边界整理成这样：

这里有一个非常重要的认知误区要澄清：边界不是要切断 Agent 之间的协作，它是在管理"协作发生的时空范围"。你完全可以让两个 Agent 共享一部分记忆、交叉引用一部分知识——但前提是这种交叉是设计出来的、走明确通道的，而不是因为代码偷懒把所有东西堆在一起然后祈祷模型分行。边界管理的本质，是把"隐性的、全量的混合"改成"显性的、按需的连通"。

3. 边界模糊与边界泄漏：故障模式的工程学分类

边界在真实系统里从来不是二进制——不是"有"或"没有"，而是"多清楚"和"多糊"。你可以把所有 Agent 塞进一个共享上下文的 prompt 里，它们之间的边界几乎为零，协作成本也几乎为零，但系统行为完全失控；你也可以让每个 Agent 完全隔离、老死不相往来，协作彻底消失。绝大多数已上线的多 Agent 应用，都坐落在两者之间的某个模糊位置。

一旦边界模糊，就会出现几种高频故障模式。能识别出这些模式，排错的速度会快很多。我把它们分成四类：信息串扰、职责重叠、正反馈回路、资源竞态。

**信息串扰（Cross-talk）**是最常见的边界模糊病。我们把会话历史、检索结果、全局上下文一股脑塞给所有 Agent，每个 Agent 都不具备"这消息是发给我的吗"的判断力。单独的 Agent 很聪明，组合起来却会把不该作为决策依据的信息当成依据。

我调试过一个多 Agent 项目，团队用一个统一的 RAG 索引做知识检索，查询词同时命中市场部文档和技术 FAQ。结果负责产品推荐的 Agent 在介绍功能时，突然冒出一句"已知性能瓶颈包括……"。这就是知识边界失效：检索引擎把不属于当前职责的内容返回了，而 Agent 没有能力拒绝这些内容。给上下文窗口喂什么，它就会用什么——这是语言模型的底层行为，改 prompt 的作用非常有限。

**职责重叠（Responsibility Ambiguity）**则是多个 Agent 抢一个活。最常见的设计错误是：用"意图分类 + 动态路由"来决定哪个 Agent 响应，但路由的判定边界本身模糊。比如一个"通用助手"Agent 和一个"订单查询"Agent 同时覆盖了"我的订单到哪了"这类诉求，意图分类器稍微有波动，请求就会路由到不同 Agent 手里，用户得到的回复口径自然不一致。更麻烦的是，当路由逻辑不够稳定时，系统会在不同运行版本之间"随机切换人格"，这种故障极难复现，因为日志里每个请求看起来都合理。

**正反馈回路（Positive Feedback Loop）**是我在文章开头那个案例里遇到的故障模式：A 的输出变成 B 的输入，B 的输出再反过来成为 A 的输入，循环中每次迭代都会让偏差放大。语言模型的"输出"天生带有非确定性，这种微小的偏差原本不会造成大问题，但反馈回路会把它变成一次次"复读"——每次复读不仅不修正，还会在一个错误的方向上添砖加瓦。我见过最夸张的案例里，两个 Agent 在 7 轮互相对话之后，就把一个最初的"可能有优惠"的猜测，发展成了一份包含具体折扣额度、适用范围和截止日期的完整"政策文档"。没有任何人编造过它，它就是这么一环一环长出来的。

**资源竞态（Resource Contention）**看起来与前三种不同，它更像是并发系统里的普通问题，但在多 Agent 语境下有特殊危害。多个 Agent 同时请求同一个外部 API、同时写同一个数据库表、同时竞争同一个模型服务的配额。你不拦着，它们就会互相踩踏，轻则性能劣化，重则数据互相覆盖。这类问题在单 Agent 的系统里几乎不存在，因为只有一个执行者；但到了多 Agent 并行执行时，就成了常态而非偶发。

把这四种故障模式放在一起看，能得出一个工程学层面的结论：边界是控制故障传播半径的手段。结构工程里，防火墙的作用不是阻止火灾发生，而是让火灾在一个房间内烧完，不蔓延到整栋楼。多 Agent 系统的道理一模一样。信息串扰、职责重叠、反馈回路、资源竞态，本质都是故障越过了边界，从局部向全局扩散。边界设计的水平，不体现在系统不出错的时侯，恰恰体现在它出错的时侯影响面有多大。

4. 把边界焊死：一套可落地的边界设计方法

讲了这么多理论，下面来点能直接抄作业的东西。这部分是我在实际项目里逐步摸索出来的边界设计框架，分为五个层面：编排层、状态层、知识层、协议层、运行前预检。它们不是可选组合，而是一个完整链路——任何一个层面缺失，边界都会有漏风的地方。

4.1 编排层：每个 Agent 都要有一张"角色卡片"

在编排层（也就是定义执行流程的层面），最容易被跳过的就是"角色建模"。大多数框架（CrewAI 的 Agent 定义、LangGraph 的节点、AutoGen 的 ConversableAgent）都允许你填 role 和 description，但很少有人真正把角色描述写成一份严格的、可审计的"职责说明书"。

我的做法是给每个 Agent 维护一张结构化的角色卡片，不只是一个笼统的名字加一句话描述。它长这样：

role_card = { "id": "sales_assistant", "display_name": "售前助手", "responsibilities": [ "根据用户需求推荐商品", "解答价格、库存、物流时效问题", "在用户表达售后诉求时，将会话转交给 after_sales_assistant" ], "forbidden_actions": [ "承诺退款政策", "修改用户的订单状态", "访问售后申诉渠道" ], "knowledge_domains": [ "product_catalog", "pricing", "inventory" ], "memory_namespaces": ["memory:sales:*"], "allowed_tools": ["search_products", "get_price", "check_stock", "create_handoff_ticket"] }

这张卡片不是给人看的，是给两处代码看的：一是编排引擎，它根据角色卡片决定任务路由；二是一个我后面会讲到的"运行前预检"模块，它负责在 Agent 执行动作前做边界校验。

角色卡片的关键是forbidden_actions。大多数团队只定义了"Agent 能做什么"，没定义"Agent 不能做什么"。对于一个自带非确定性的模型来说，只声明正面清单是不够的——模型在读到一个场景时，"没被禁止"会被理解成"可以做"。你必须把所有高危动作显式写出来。

4.2 状态层：记忆分区与命名空间隔离

记忆边界是所有边界里最值钱也最容易被滥用的一种。我见过太多团队把"多 Agent 协作"实现成了"几个 Agent 共享同一个向量数据库集合"，这等于让每个 Agent 都能读写所有人的日记。

我的建议是：长期记忆按命名空间严格分区，命名规则就用角色 ID 作为前缀，配合完整路径：

# 不推荐：所有 Agent 共享同一个 collection collection = vector_db.get_collection("shared_memory") # 推荐：每个 Agent 有独立的命名空间，只有显式声明的跨域通道才可访问 sales_memory = vector_db.get_collection("memory:sales") after_sales_memory = vector_db.get_collection("memory:after_sales") # 跨域通道（需在角色卡片里显式授权） handoff_notes = vector_db.get_collection("memory:handoff")

这里有个工程细节值得说清楚：短期记忆（会话上下文）和长期记忆（持久化存储）要分开处理。短期记忆通常只存在于单个任务执行链中，Agent 之间共享短期记忆在某些场景下是合理的（比如让多个子 Agent 共同阅读同一份用户输入）。但长期记忆一旦共享，污染就是永久性的——今天一个 Agent 写错的事实，三个月后还会被另一个 Agent 引用。

如果你用的是 LangGraph，你的 State 结构本身就承担了一部分记忆边界功能。不要把整个会话历史塞进一个全局 State 里让所有节点都读，而应该在 State 里显式区分shared_context和private_context。每个节点声明它只能写自己的private_context，公共区域的写入要走专门的handoff函数。

4.3 知识层：检索必须收口到职责域

RAG 是目前多 Agent 系统最常用的知识增强手段，但绝大多数实现都有同一个问题：知识被"摊开"给所有 Agent。一个检索接口，一个向量库，谁的查询都能在这一个池子里捞。这么做表面上是"最大化信息复用"，实际上是在给信息串扰开大门。

正确的做法是给知识检索加上和权限系统一样的细粒度控制。RAG 架构不变，但在索引和查询之间插一层"权限过滤"：

def retrieve_knowledge(agent_role: str, query: str, top_k: int = 5): # 第一步：先从角色卡片中取出该 Agent 的知识域白名单 allowed_domains = role_card_registry.get(agent_role)["knowledge_domains"] # 第二步：在检索结果上做域过滤（也可以用向量检索前过滤更省算力） candidates = vector_db.search(query, top_k=top_k*3) filtered = [doc for doc in candidates if doc.domain in allowed_domains] # 第三步：如果过滤后结果不足，宁可少给，不要乱给 return filtered[:top_k]

这里想强调一个反直觉的工程选择：过滤后结果不足时，不要用"放宽领域"来补足。宁可让 Agent 明确说"该信息不在我的查询范围内"，也不要给它越界的上下文。很多工程师担心"信息不够 → 回答质量差"，但实际上，多 Agent 系统里因为信息越界而回答错误，远比信息不足严重得多——前者是系统性错误，后者只是不完整。

4.4 协议层：把协作设计成交接，不是设计成"讨论"

在多 Agent 系统里，Agent 之间的协作方式可以分成两类：一类是"大家一起讨论同一个问题"，另一类是"按契约交接任务"。前者适合头脑风暴、方案评审，但它在生产系统里极其危险，因为它没有任何边界保障——A 的话会自然流入 B 的上下文，B 的话又会回流到 A。后者才是生产级应用的常态。

我的经验是：将"信息交换"重构为"契约交接"。两个 Agent 之间不直接传递开放式对话内容，而是传一个结构化的交接消息，里面规定了字段、语义和有效范围：

handoff_message = { "type": "handoff.sales_to_after_sales", "source_agent": "sales_assistant", "target_agent": "after_sales_assistant", "user_intent_snapshot": "用户要求退货，商品ID可查", "critical_facts": [ {"field": "order_id", "value": "20250115-77889"}, {"field": "issued_complaint", "value": "物流延迟导致拒收"} ], "explicitly_excluded": [ "销售承诺过的优惠信息（可能不存在）" ], "expires_at": "2025-01-18T00:00:00Z" }

这个交接消息就是两个系统之间的"接口"——它把所有 Agent 间传递的信息收拢到明确定义的字段里，减少了开放式内容随意漂移。工程上，你应该给交接消息加 schema 校验，字段名写错、类型不对，直接拒绝交接。这听起来死板，但它能拦下大量因为"模型随手写了个字段"而导致的隐性故障。

提示：交接消息不是文档，它是运行时数据结构。不要让它携带大段自然语言总结，尽量只带结构化字段。自然语言总结会把"原 Agent 的偏见"打包传递到下一个 Agent 手里。

4.5 运行前预检：给每个动作装一个"限位器"

最后一步是运行时校验，也是我后面称它为"限位器"的东西：在多 Agent 框架里，Agent 要调工具、写记忆、发消息之前，都会经过一个拦截层。拦截层检查这次动作是否在角色卡片的允许范围内。越权动作直接拒绝，并记录一条审计日志。

用伪代码表示就是：

def guard_action(agent_role: str, action: dict) -> dict: card = role_card_registry.get(agent_role) if action["type"] == "tool_call": if action["tool_name"] not in card["allowed_tools"]: return {"allowed": False, "reason": "tool_not_in_whitelist"} target = action.get("target", "") # 一些工具需要路径级权限：例如"只读"与"写" if action["method"] == "write" and not card["allowed_write_targets"].match(target): return {"allowed": False, "reason": "write_target_out_of_scope"} if action["type"] == "memory_write": ns = action["memory_namespace"] if not any(ns.startswith(prefix) for prefix in card["memory_namespaces"]): return {"allowed": False, "reason": "memory_namespace_forbidden"} if action["type"] == "message_send": # 允许谁发给谁也要在编排层显式定义 if action["target_agent"] not in card["allowed_participants"]: return {"allowed": False, "reason": "communication_not_configured"} return {"allowed": True}

这个"限位器"是所有边界设计里投资回报率最高的一块。它把边界问题从"信任模型"变成了"执行纪律"——你再也不依赖"模型自觉不越界"，而是从机制上保证它越不了界。很多框架（比如 LangGraph 的interrupt机制、自研 Agent 的tool_executor）都可以挂这种拦截层，改造量并不大。

5. 边界不是死的：运行时监控与动态治理

边界设计得再完美，也只是"预配置"。运行中的多 Agent 系统是活的：知识库在变、需求在变、Agent 的角色职责也在演进。边界不能设计完就一劳永逸，你需要一套观测手段来看边界在哪断了、在哪堵了、在哪又太宽了。

5.1 如何观测边界泄漏

多 Agent 系统排错的最大困难是"不知道谁在什么时侯读到了什么"。单体 Agent 出了错，你可以直接复现它的 prompt；多 Agent 系统出错，你得先搞清楚错误信息是从哪个 Agent 的哪段输入里"串"进来的。

我的做法是给所有 Agent 加统一的审计埋点，每条推理记录至少包含三件事：这个 Agent 读了哪些知识条目（知识边界观测）、写了哪些记忆（状态边界观测）、调了哪些工具（权限边界观测）。不是可选的调试日志，而是强制全量记录。你可以用现成的链路追踪工具（LangSmith、Langfuse），也可以自己在工具执行层里包一层记录函数。重点不是工具，而是你要保证每一个"读写动作"都能对得上一个"Agent 身份"。

有了全量审计日志，边界泄漏就变成可查询的了。我最常跑的几个排查 SQL 思路供参考：

• 找跨域引用：查某一天的日志，看看售后 Agent 的回复里引用了多少条知识来源属于product_catalog域。如果比例超过个位数，说明知识过滤有漏洞。
• 找重复应答：在同一个会话 ID 下，如果两个不同 Agent 都产生了面向用户的最终回复，说明职责边界在路由层失效了。
• 找记忆互写：查memory_write记录，看哪个 Agent 写进了不属于自己命名空间的消息。这个要在预检层拦截，但如果拦截层部署晚了，历史记录里也能翻出来。

5.2 一组值得跟踪的边界健康指标

除了日志排查，我建议日常盯三个指标。

域外引用率：Agent 在回复文本中引用了多少知识库域之外的条目。实现方式是给每条知识条目附加域标签，并通过 LLM 或规则事后抽取回复内容来比对。这个指标最直接地反映知识边界的破坏程度。

职责重叠指数：在一段统计周期内，多个 Agent 回复同一类用户请求的占比。计算方法是把用户请求做意图聚类，然后看每个聚类下有多个 Agent 产出过最终答复的比例。这个值高，说明路由边界不清晰，需要马上调整。

上下文污染比：在 Agent 的实际上下文窗口中，与本角色无关 message 的 token 占比。这个指标需要你在把信息塞进上下文时就打标。如果某天这个值突然升高，往往意味着某个跨 Agent 通路没有按预期工作。

这三个指标不需要像 Prometheus 监控那样搞得很重，可以放在每日离线任务里算。多 Agent 应用初期的边界问题不会按小时爆发，按天观察完全来得及。

5.3 边界的动态调整：治理循环与熔断

边界在运行期是可以且应该被调整的。我的做法是每个迭代周期做一次边界评审，流程简化下来是三步：

• 找"越界"事件：从审计日志里找出所有被guard_action拦截的动作、所有域外引用率超标的会话。
• 判断"越界"原因：是一个 Agent 的任务定义确实需要扩大知识域？还是路由写得不合理，把一个不该发给它的请求分给它了？这步务必区分"边界设窄了"和"模型行为失控"，前者需要放宽，后者需要收紧。
• 执行调整：修改角色卡片或路由逻辑，把新的边界配置部署上去。角色卡片应该是可热更新的配置，而不是写死在代码里的定义。

除了日常调整，还必须有熔断机制。当一个 Agent 的越界行为事件频发、而且每次都产生用户可见的错误时，不要让它继续在旁边"半越界运行"——直接把它的权限降级为只读，切断它的工具调用链路，等人工 review 完再恢复。这个降级动作跟后端系统把一个异常节点从负载均衡池里摘掉是一个道理。系统可以损失一部分"智能能力"，但不能承担持续扩散的错误。

5.4 反馈回路的抑制：边界里的"止损"通道

前文提到的正反馈回路，在运行时治理中值得单独讲一下。回路一旦形成，靠调整角色卡片是不够的，因为它是两个 Agent 之间"动态涌现"的相互增强，不体现在任何单一 Agent 的越界行为上。

我自己项目里最管用的办法有两条。第一，在交接消息上附加"事实来源链"：每个 Critical Fact 都标注来源 Agent 和产生时间，接收 Agent 在引用这个事实时，如果发现"来源 Agent"已经和自己处于同一协作路径上，就禁止将其作为新依据继续传递——切断自我循环。第二，对 Agent 间连续的对话轮次设置阈值：同一任务链内部，Agent 之间的消息往复超过 N 轮（我常用 3 到 5 轮）就直接中断，要求一个角色卡片之外的人工节点（或者更上级的编排器）做一次汇总和裁决，再决定是否继续。这个限制看起来粗暴，但正是"防火墙截断火灾蔓延"的多 Agent 版本。

6. 边界治理的分寸感：冗余、安全裕度与演进节奏

讲到这里，你可能会产生一个印象：边界越多越森严越好。这其实是对工程学方法的误解。结构工程里的边界（墙体、伸缩缝、柱距）从来不是越多越好，而是恰到好处。边界设计的关键不是"砍断所有连接"，而是给每个必要的连接匹配足够的安全裕度。

在多 Agent 系统里，这个分寸感体现在三个地方。

第一个地方是容许"有节制的冗余"。两个 Agent 偶尔都能回答同类问题，本身不是问题；问题是这种冗余是否在预期之内、是否有一致性保障。如果你的"边界"设计成"绝对不重叠"，你会损失系统天然的容错能力——一个 Agent 挂了，另一个可以顶上。我通常允许职责边界存在 10% 左右的"灰区"，但这部分灰区必须经过同一套知识源、同一个回复口径的校验，而不是放任两个 Agent 各自发挥。

第二个地方是显式设计"跨边界通道"，而不是等泄漏发生后再补救。比如一个"编辑" Agent 和"审核" Agent 之间，它们确实需要共享一份草稿内容。你不能因为它们属于不同角色就把存储完全隔离，而是应该在角色卡片里显式声明一个共享命名空间memory:drafts:*，两个角色都有读写权限，其他角色一律禁止。这样，跨边界的协作是"被批准的、被记录的"，而不是"漏过去的"。边界管理做久了你会发现，真正让你省心的工作，就是把所有隐式泄漏变成显式授权。

第三个地方是边界治理的演进节奏。在一套多 Agent 系统刚上线时，边界设得紧一些、宁可误伤不可放任；上线跑通几个业务场景、积累了一批审计日志后，再按照真实数据把边界调松或调细。很多人一上来就追求"完美平衡"，搞出一套极其复杂的动态路由和共享协议，结果系统复杂到根本跑不动。我更推荐的做法是：先拿角色卡片 + 命名空间隔离 + 运行前预检这三板斧把骨架立起来，用两个星期观察真实流量，再动手加"动态调整"和"熔断"这类高级机制。边界治理是一个循环往复打磨的过程，不是一次交付的文物。

最后分享一个我反复踩过坑之后总结出的经验：多 Agent 系统的稳定性，不取决于你用的框架有多先进、模型有多聪明，而取决于你能不能回答清楚三个朴素的问题——"在这条任务链上，每一步应该是谁在做？它被允许依赖哪些信息？它做完之后，把结果交给谁、以什么格式交？"这三个问题的答案越明确，你的边界就越清晰；边界越清晰，一个 Agent 的失控就越难演化成整个系统的崩溃。至于"协作得更好"这件事，等边界立住了，再谈也不迟。