最近整理 LoopX 的 Agentic Software 实践，我越来越觉得，有两条工程主线需要放在一起看： 1. Agent 如何理解和操作一个语义系统… · @huangruiteng · TwKit

@huangruiteng

最近整理 LoopX 的 Agentic Software 实践，我越来越觉得，有两条工程主线需要放在一起看： 1. Agent 如何理解和操作一个语义系统，2. 这个系统如何在异步、并发和局部失败中持续工作。 语义这一侧，目标、约束、证据和权限要有明确的含义。人的一句纠正、新的实验结果、工作状态的变化，都可能改变下一步应该做什么，以及原来的结论还能适用于哪里。 这也涉及 Agent 与系统交互的效率。它需要在合理的上下文、工具调用和时间成本内，拿到完整且适用的信息，表达明确动作，再读回真实结果。CLI output、统一词表、可组合接口和按需下钻，都在影响这条路径。信息压缩之后，决定行动所必需的依据仍要完整。 执行结果还要经过验证，进入下一次决策。人的纠正要改变验收或行动；失败要能被识别、恢复并继续推进。反馈被保存、被检索到，是这条链路中的中间状态。 分布式系统这一侧，则要处理另一组现实：消息可能延迟、重复或乱序；工具可能已经执行，调用方却没有收到回执；恢复出的上下文可能完整，其中的授权或证据却已经失效。 两条线在这里耦合起来。比如微基准通过后，人补了一句“真正关心的是混合流量的 p95”。系统需要保留旧结果的适用范围，修订验收，再安排服务级对照。如果实验提交后断连，还得沿原操作身份确认是否已经启动。这时，“按新标准继续”与“避免重复执行”必须同时成立。 沿着这条主线，接口成本、语义收敛、状态归属、组合恢复和反馈采用，才能放进同一个工程问题里讨论： Agentic Software 需要构建一个让 Agent 能够高效理解、操作、验证和修订的语义系统，让决策、执行与反馈闭环在分布式环境中持续成立。 两者的耦合，也正是新的工程复杂度所在。 https://loopx-project.github.io/loopx/blog/zh/semantic-software-development/#semantics

曝光 260 · 评论 1 · 点赞 9 · 书签 4