10 月 31 号晚上，DeepSeek Harness 团队扔出一篇《Super-agent 设计探索：迈向更自主的 Agent 系统》，顺手把原型传到了 GitHub：deepseek-ai/dsh-superagent-prototype。

严格说这不是论文，是一份万字内部设计文档的外发版。它既没训新模型，也没出新 benchmark，干的事一句话能说完——把操作系统和分布式系统里那套调度、缓存、存算分离、看门狗，重新在 Agent 身上搭了一遍。

初看有点”这不都是老东西吗”，读完才意识到，老东西被搬到这个场景，刚好踩在当下 Agent 落地最难受的几个点上。

在 Agent 里调一次远程 MCP 工具，再把结果写进文件，看起来是最没有技术含量的一步。可就是这一步，把本该秒级结束的事情拖到了二十秒，还让大量返回数据留在上下文里，既推高成本，也干扰后续判断。

这篇文章记录 mcp-proxy 从取证到落地的过程：哪里慢、试过什么、哪些判断后来被自己的数据推翻。文中出现的耗时、token、轮次都来自项目记录，外部引用列在文末。

在应用架构的设计中，领域驱动设计（Domain Driven Design，DDD）占据着非常重要的位置，可以说DDD是应用架构设计的核心。

DDD为我们提供了一种架构设计方法，既面向业务，又面向技术，从业务需求到领域建模，从领域服务到技术转化，强调开发人员与领域专家协同。DDD是埃里克·埃文斯（Eric Evans）在2003年出版的《领域驱动设计：软件核心复杂性应对之道》（Domain Driven Design: Tackling Complexity in the Heart of Software）一书中提出的具有划时代意义的重要概念，不过这种领域建模和设计的思想其实早在20世纪就有很多设计人员重视起来。DDD通过统一语言、领域模型、领域划分和服务划分等一系列手段来降低软件复杂度。

DDD的核心思想是业务与技术相结合的一种过程，既强调业务的理解，又强调应用领域建模方法的使用。DDD本质上是面向对象分析的扩展和延伸，它基于面向对象分析技术进行了分层规划，同时对其中的核心概念和划分做了详细的指引。

1. 什么是STRIDE威胁建模

计算机发明后不久，人脉就发现需要为这些信息系统处理威胁。早在1994年，NSA和DARPA就提出攻击树、威胁树等概念。1999年微软内部发表了《The threats to out products》的文章，为定义Windows全系列产品面临的安全威胁正式提出了STRIDE。随着2002年比尔.盖茨著名的《可信任计算备忘》发布，微软承诺改善软件产品的安全性，随即正式在SDL（安全开发生命周期）中采用了威胁建模。

研发团队的安全例行活动中，对于一些拥有重要数据资产、安全事件影响力大的系统除了要进行常规的渗透测试、黑白盒代码扫描以外，更应该系统定期开展威胁建模活动并对业务赋能。所以对于研发团队来说，引入先进的安全技术设计能力，构建全方位、多维度防御体系，是不懈追求的目标。

通过威胁建模，我们能够实现以下这些价值：

• 识别体系化的结构缺陷：大多数安全问题是设计缺陷问题，而不是安全性错误。威胁建模能帮助识别这些设计缺陷，从而减少风险敞口，指导安全测试，并降低因安全漏洞而造成的品牌损害或财务损失等可能性。
• 节约组织安全成本：通过对威胁进行建模，并在设计阶段建立安全性需求，降低安全设计缺陷导致的修复成本。在需求管理和威胁分析阶段，与业务开发团队高效互动，释放安全团队的专业能力，专注于高性价比的安全建设。
• 落地DevSecOps文化：通过威胁建模跑通开发和安全工具的流程集成，把风险管理嵌入产品的完整生命周期，从而推动形成完整的DevSecOps工具链。
• 满足合规要求：威胁建模是国际安全行业通用的方法论，通过向管理层和监管机构提供产品的风险管理活动的完整记录，帮助团队遵守全球法律法规要求，包括PCI DSS、GDPR、HIPAA、CSA STAR等。

STRIDE作为当前最流行的威胁建模方法，是值得研发团队引入的威胁建模的方法。STRIDE是以下英文的首字母缩写，把威胁分为6类，基本上涵盖了所有的威胁类型，帮助建模者对威胁进行建模。

• S：Spoofing（假冒）
• T：Tampering（篡改）
• R：Repudiation（抵赖）
• I：Information Disclosure（信息泄露）
• D：Denial of Service（拒绝服务）
• E：Elevation of Privilege（权限提升）

2. STRIDE威胁建模整体流程

STRIDE威胁建模方法贯穿于整体风险分析流程，将安全需求分析和安全设计相互融合。STRIDE威胁建模不仅仅可以用于安全需求分析和设计，也可用于后续安全开发环节。

为什么引入可测试性设计？

在讨论可测试性之前，我们不妨先来思考一个问题：

当我们来盖一栋楼，如果不能保证钢筋、水泥、砖土质量合格，却想要盖出合格的大楼来，这个可能吗？

然而，很多团队的软件开发就是这么做的。很荒唐吧！

对于支持函数式编程的语言来说，支持闭包是一个非常必要的能力。但是我们在Rust中使用闭包的时候经常会出现一些莫名其妙、无法理解的错误。

你可能会这样的经历：你非常兴奋的使用闭包这个特性写了一段自认牛逼的代码，发现根本无法编译通，修改了好几次，终于在编译器的友（残）好（暴）提（敲）示（打）下，终于编译完成，执行成功了，但是下一次依然碰到同样的遭遇。

为了避免持续出现这样的情况，我们来系统的看一看Rust中的闭包。

刚开始学习Rust时，我觉得它的模块机制难以理解。后来才明白是自己想多了，Rust模块其实就是命名空间，仅此而已。它的crate倒更像是其他语言的模块。

去年 11 月，Numpy团队的一份声明引发了Python社区的关注：这一科学计算库即将放弃对于 Python 2.7 的支持，全面转向Python 3。

声明原文Plan for dropping Python 2.7 support

本文谈了创建产品的原则和理想的创业团队应具备的各种技能

1. 如果你不能销售它，不要建立它
2. 如果你不能建立它，不要销售它

麻省理工学院的Bill Aulet说 ，企业的唯一必要和充分条件是付费客户。 但这并不是一个好的业务的充分条件;相反，我们需要使用IDEO的Tim Brown提出的“设计思维”方法作为指南，找到客户需求的最佳选择，在技术上可行，在商业上可行。 然后我们需要卖掉它，继续卖它，再卖一些（重要的话说三遍）。

本文主要内容都来自于今年二月发布的RFC8071 - NETCONF Call Home and RESTCONF Call Home，该RFC从2015年4月提出到最终发布一共修改了17个版本，其间修改内容可以点击查看详细内容。

介绍

NETCONF Call Home支持两种安全传输网络配置协议分别是Secure Shell(SSH)和传输层安全(TLS)。

NETCONF协议​​的绑定到SSH在RFC6242中定义。
NETCONF协议​​的绑定到TLS在RFC7589中定义。
SSH协议在RFC4253中定义，TLS协议是在RFC5246中定义。SSH和TLS协议都是TCP协议之上的协议。