叙事状态、角色知识和可调用的任务工具里，最难的通常不是把主路径跑通，而是明确谁能改状态、失败后留下什么，以及怎样复现判断。下面只围绕一个可落地的做法展开。

角色系统的重点不是让对白更长，而是让每次行动有明确边界。策划定义角色能知道什么、能改变什么；客户端和服务端分别维护状态与权限。

这篇只讨论 美术资产生产管线 的一个可验证切面。输入是风格说明、资产规格、来源记录、生成参数和人工审核意见；输出要能被下游检查。范围写清楚，后面的取舍才有依据。

做 NPC 决策链路，最怕一开始就堆“通用能力”。先把输入和结果收窄：这里需要处理的是感知快照、黑板状态、动作冷却和当前任务。题目里的问题应当落在这条链路上，别用抽象口号替代设计。

在我们的多 Agent 协作系统（Multi-Agent System）上线初期，遇到了极具代表性的瘫痪故障：系统架构包含一个负责调研的和一个负责撰写的。在一次处理复杂行业报告任务时，Researcher在等待Writer给出提纲反馈，而Writer也在等待Researcher补充数据。两个非确定性的 Agent 在自由对话模式下，陷入了经典的“死锁（Deadlock）”状态。后台两个协程持续挂起

Agent 前端编排的核心是把每一步工具调用建模为状态机节点，用快照与中断信号贯穿 UI 与执行层。落地建议：第一，每步明确六状态枚举，禁止用单一 loading 走天下。第二，副作用步骤必须 requireHumanConfirm，maxRetries 设为 0。禁止自动重试不可逆操作。第三，重试以 step 为粒度，配指数退避避免压垮下游。第四，中间产物按用户视角裁剪展示，原始数据折叠到详情层

在 LLM 应用快速演进的当下，Token 消费成本是技术团队无法回避的核心课题。通过部署多级 Token 预算控制闸门，配合动态模型路由与降级策略，能够在保障业务功能完备性的同时，最大程度减少非必要的花费。大模型的非确定性特征要求我们在架构层面树立起强烈的成本防范意识，使用确定性的工程防线为企业的财务安全保驾护航。

绝对不要让大模型独掌循环控制权：必须设置MaxSteps（如最多允许 5~8 轮）硬性物理上限，防止无限重试。校验 Tool Call 幂等 Hash：连续相同参数的 Tool Call 超过 2~3 次，即可判断模型陷入昏厥，必须强制熔断。全局 Context 必须挂 Timeout：任何 Agent 协程必须绑定超时 Context，防止单个非确定性任务永久占用计算资源。多级降级预案：当 Ag

AI NPC 数量增加后，最先失控的往往不是模型调用速度，而是过期结果覆盖新状态。角色已经离开战斗，几秒前的“发起攻击”才返回，这类问题不能靠增加并发解决。

必须引入：所有容器化 Go 项目必须在main.go中匿名导入。警惕 cgroup CFS Quota：容器使用率看起来不高，但并发线程过多会迅速打满 100ms 窗口配额引发 Throttle。监控指标：将容器 CPU Throttle 比例暴露给 Prometheus，大于 5% 即代表配置存在严重冲突。合理设置 CFS Period：在 K8s API 中对极高并发服务设置为 20ms 以降