不少团队做 Agent，现在的路径基本是先 Fork 一个成熟仓库，再围绕业务裁剪，而不是从零搭服务。这个选择本身没问题，问题在于挑项目的标准。
Star 数高不高，其实没那么重要。真正值得看的是几件事：最近有没有持续维护，issue 响应快不快，架构是不是方便替换模型和工具，评测链路全不全，依赖版本和许可证能不能长期落地。这套标准放在通用 Agent 场景下已经够用，但如果目标客户是政务和大型企业，这套标准需要再往下挖一层——因为企业级场景要的从来不是"能跑起来的 Demo"，而是可审计、可控、数据主权明确的系统。这层差异，才是企业级 Agent 工程真正的门槛。
权限隔离不是功能，是合规审查的对象
多租户场景下的 RBAC、skills 不可见、记忆会话隔离，这几件事做出来只是第一步。企业客户尤其是政务客户，看的不是"你有没有权限隔离功能"，而是这套隔离能不能经得起合规审查——谁在什么时间通过哪个 Agent 调用了什么工具、传了什么参数、模型怎么做的决策，这条链路要能完整回溯。观测数据本身也不例外：技术团队排查问题时，同样不能因为职责需要就看到某个客户的调用链细节。可观测数据和业务数据一样，需要按租户做权限隔离，这一点很容易被忽略，因为大家默认观测数据是"给自己人看的"。
零侵入接入，本质是责任归属问题
Agent 要调用企业内部系统，多数团队的直觉是找技术方案：API 网关、RPA、只读副本加脱敏视图，按优先级挑一个能用的接。但在政务和国企语境下，“零侵入"这个词往往不是技术选型问题，而是采购和合规问题——能不能改造老系统、出了问题算谁的，这些往往比技术方案本身更决定最终落地路径。很多老系统只有 Web 界面没有 API，零侵入实际上会退化成模拟用户操作，这条路径的核心不是稳定性（当然也重要），而是审计链路要足够完整。更关键的一条原则是：写操作必须留有人工确认或回滚窗口，不能让 Agent 单方面完成一次不可逆的业务操作。这一点，其实比"自动化程度"更值得作为卖点讲——不是 Agent 能替代多少人工，而是 Agent 在哪个环节主动让位给人。
评测体系要多一层安全边界测试
企业级评测比通用 Agent 评测多一层，功能正确性之外，需要单独建一批验证权限穿透的用例——能不能通过某种输入方式，让某个角色的 Agent 越权调用不该看到的工具或 skill。这一层在已有 RBAC 的基础上其实不难补，因为角色和工具的映射关系已经明确，可以直接反向生成"应该被拒绝"的测试集。另外，纯自动化的评测很难完全替代人工合规抽检，现实的分层方式是：自动化覆盖回归和一致性（模型或 prompt 升级后输出有没有漂移），人工抽样覆盖合规和业务语义正确性，两者互补而不是互相替代。
自进化 skills，需要泼一点冷水
这大概是最容易讲成故事、也最容易讲过头的方向。不可控的自我修改，在政务和大型企业客户那里基本是不可接受的——他们要的是可解释、可审计、可回滚，“越用越聪明但说不清楚为什么变聪明"这种叙事，在合规审查环节反而是减分项。更现实的路径，是把"进化"做成一条受控的、版本化的流程：使用日志里识别高频失败或高频人工修正的模式，生成新 skill 草案，人工审核后灰度上线，每个版本可 diff、可回滚。反馈信号的采集才是真正的难点——企业客户很少给显式标注，更现实的隐式信号是人工是否修改了 Agent 的输出、修改幅度多大，这个 diff 大小本身就可以当质量代理指标。而且这条演化链路也要延续租户隔离的逻辑：一个客户的使用数据训出来的 skill 变体，不能流入另一个客户的 skill 库，这不只是隔离问题，在政务客户那里可能直接是数据合规红线。
往底层看，这些问题并不新鲜
如果把这些问题排开来看，会发现它们和数据密集型系统设计里讨论的问题高度同构：上下文的记忆模型对应 schema 的演化和向后兼容；context window 的冷热分层对应存储引擎在写多读少和读多读少之间的权衡；多 Agent 状态同步对应强一致性和最终一致性的取舍；租户隔离本质上就是按 tenant 做 partition；实时的工具调用循环和夜间批量的评测、skill 生成任务，对应的是速度层和批处理层的关系。这些问题在分布式系统领域已经被研究了几十年，工程上的权衡框架可以直接借用，不需要在 Agent 领域重新发明一遍。
这也解释了从业者知识底座的迁移方向：过去需要理解 JVM 内存模型、GC 策略、数据库索引和查询优化，现在这些知识某种程度上还在起作用，只是换了个场景——但确实有一块是完全新增的，无法从旧知识直接迁移：Transformer 的 attention 机制决定了长上下文的计算成本，训练范式决定了模型能力的边界从哪来，scaling law 和涌现能力的争议决定了要不要相信"模型以后自然会变强”。这一条尤其值得谨慎，因为学界对涌现能力本身就有分歧，稳妥的工程假设是模型能力提升不可预测，架构因此要做成可插拔替换模型，而不是赌某个模型会一直强下去。
从 Prompt Engineering 到 Harness Engineering，为什么会这样走
这条路径是单次交互优化、到状态管理、再到系统工程化的演化，和一个应用从单机脚本长成分布式系统是同一条路。早期 context window 很小，核心矛盾是一次性输入怎么写才能激发模型能力；context window 变大之后，模型能做多轮任务了，核心矛盾变成怎么管理跨多轮的状态；到了现在，不再是单次模型调用，而是模型加工具加多 Agent 协作加长时间运行的任务编排，核心矛盾变成怎么设计一个可靠系统，让模型的不确定性输出能在其中安全运行。
这个演化的根本原因，是模型能力在持续提升，但模型的不确定性并没有随之消失——反而因为任务链路变得更长、更复杂，这种不确定性被系统性地放大了。工程重心因此被迫从"怎么激发模型能力"转移到"怎么在不可靠的组件上构建可靠系统”，而这正是分布式系统几十年一直在解决的问题，只是这次不可靠的组件从网络和磁盘换成了 LLM。
回到最初的选型标准——为什么 star 数不重要，为什么要看维护活跃度、架构可替换性、评测链路完整度。本质上，这些标准衡量的不是"这个项目现在多聪明"，而是"这个项目能不能在一个持续变化、本质不可靠的底层上，撑起一套可审计、可控的系统"。对企业客户而言，尤其是政务和大型企业，真正的壁垒从来不是模型本身有多先进，而是这套工程能力本身能不能经得起时间和合规审查的考验。